Targeting advertising in a home retail banking delivery service

ABSTRACT

A practical system and method for the remote distribution of financial services (e.g., home banking and bill-paying) involves distributing portable terminals to a user base. The terminals include a multi-line display, keys &#34;pointing to&#34; lines on the display, and additional keys. Contact is established between the terminals and a central computer operated by a service provider, preferably over a dial-up telephone line and a packet data network. Information exchange between the central computer and the terminal solicits information from the terminal user related to requested financial services (e.g., for billpaying, the user provides payee selection and amount and his bank account PIN number). The central computer then transmits a message over a conventional ATM network debiting the user&#39;s bank account in real time, and may pay the specified payees the specified amount electronically or in other ways as appropriate. Payments and transfers may be scheduled in advance or on a periodic basis. Because the central computer interacts with the user&#39;s bank as a standard POS or ATM network node, no significant software changes are required at the banks&#39; computers. The terminal interface is extremely user-friendly and incorporates some features of standard ATM user interfaces so as to reduce new user anxiety.

This is a continuing patent application of patent application Ser. No.07/975,334 filed Nov. 16, 1992, entitled "SCREEN TERMINAL FOR REMOTEDELIERY OF RETAIL BANKING SERVICES AND OTHER INFORMATION," which is acontinuation-in-part of patent application Ser. No. 07/448,170 filedDec. 8, 1989, which issued as U.S. Pat. No. 5,220,501 on Jun. 15, 1994.

FIELD OF THE INVENTION

The present invention relates to a method and system for distributingfinancial and other services to remote locations, and more specifically,provides banking type financial transaction handling via remote dataterminals located in users' homes, offices or other locations (i.e.,"home banking" or "remote banking"). Still more specifically, one aspectof the present invention involves using the ATM (automatic tellermachine) network (interchange) as a data communications network forconducting banking financial transactions from homes and offices.

BACKGROUND AND SUMMARY OF THE INVENTION

Not long ago, "home banking" was thought to be just around the corner.With the advent of relatively inexpensive, powerful personal computers,the computer industry hoped (and predicted) that a personal computerwith communications capability (e.g., modem) would soon find its wayinto every home.

It was generally believed by many that the home computer would become acentral, integrated part of everyday life and would proliferate as haveradio and television receivers in past decades. It was expected thatpeople would prepare and file their income tax returns by computer,conduct most or all financial transactions (including billpaying)through software interfacing their personal computer andtelecommunications lines with banks and other financial institutions,etc. The home personal computer was expected to largely replace the U.S.Postal Service as a means of communicating with and contacting theoutside world. People would draft personal letters using word processingsoftware on the personal computer and telecommunicate the letterselectronically to the intended recipient over telecommunicationsnetworks. It was expected that shopping would be done electronically byperusing electronic merchandise and grocery catalogs "online" andplacing orders electronically over a telecommunications data network;and that even newspapers would be read electronically "online" (thusobviating the need for delivery of hard copy).

A few banks and other financial institutions actually developed "homebanking" systems designed to interface with home personal computersexpected to soon be found in most households.

For a variety of reasons, the dream of a world-wide network of homecomputers providing a vast array of electronic services to a majority ofthe inhabitants of industrialized nations has simply not been realized.

Ordinary people are generally not used to computers and many avoid themwhenever possible. While the next generation may be highly computerliterate, many of their parents and grandparents have little or nocomputer experience and would much rather continue doing things "the oldway." Even computer literates who own home personal computers find useof the computer to be relatively limited. As one example, it continuesto be relatively expensive and impractical to send "mail"electronically. Telecommunicating over telephone lines is relativelyexpensive, and only just recently have regional telephone companiesentered the public data network (PDN) business thereby increasingcapacity and reducing user costs. Moreover, most intended electronicmail recipients do not even have computers, the necessary communicationsequipment and the knowledge and experience.

Perhaps more importantly, the "learning curve" associated withfamiliarizing oneself with new software is often so steep that evencomputer literate people look upon learning a new software package withgreat disdain and apprehension. Thousands upon thousands of differentsoftware packages are on the market, but the top sellers are typicallythe first packages to be introduced. This is because users tend tocontinue to use software they already know and resist learning newpackages unless they are convinced the effort will be worthwhile. Even"user friendly" software may be very time consuming to learn. Many userswould probably prefer to continue their banking transactions in "the oldway" rather than spending even only a few hours learning a completelynew home banking software package.

In addition, the cost of providing home banking services have beenenormous. Service providers incur very high communications costs inlinking their central processors with PC users, banks, and payees(merchants). Many payees also do not accept electronic payments (forlack of substantial volume), forcing service providers to make costlypaper-based payments. Settlements processing can also be costly, asbanks must install special purpose software and operating procedures.These and other costs have been passed along to consumers, therebydampening the demand for home banking services.

Thus, although a small percentage of people have effectively come toutilize and rely upon some of the vast variety of services accessiblethrough a home computer as an integral part of their daily lives, thevast majority continue to communicate by post and telephone, shop byvisiting retail stores or leafing through hard copy catalogs received inthe mail, and pay their bills by writing checks and sending them throughthe mails.

In part because of the problems discussed above, PC-based home bankingis not yet a practical reality for most consumers. In fact, many homebanking programs launched in the past have been declared failures anddiscontinued. See, for example,

Egner, "Not Quite Ready for Home Banking", The EFT Sourcebook, pp171-175 (1988); and

Tyson, "`Survival` Kit: Pens and Stamps Instead of Video", AmericanBanker (Mar. 16, 1989).

Few corporations continue to market cumbersome, hard-to-use, PC andmodem-based home banking systems developed a few years ago. Covidea, ajoint venture between Chemical Bank and AT&T, was the earliest, mostnotable PC-based home banking enterprise. After $70 million ininvestment and nearly 10 years of development and marketing, Covidearecently terminated its operations. Chemical and AT&T cited obsoletetechnology as the principal reason for closing operations.Knight-Ridder, AMR and others have ceased operating their PC-based homebanking services. The following institutions, however, continue tooperate home banking systems:

    ______________________________________    Operator         Name of Service                                 Est. Users    ______________________________________    Bank of America  Homebanking 37,000    Manufacturers Hanover                     Excel       7,000    Citibank         Direct Access                                 15,000    Chase Manhattan  Spectrum    5,000    Madison Bank     Home Teller 2,000    Princeton Telecom                     licensed to banks                                 2,000    Harbinger Computer                     licensed to banks                                 2,000    Prodigy          licensed to banks                                 10,000    ______________________________________     Source: Teleservices Report, Arlen Communications, 1987 Videotext Industr     Association, 1988

Prodigy (a joint venture between IBM and Sears) is the primary majoroperator actively pursuing the national market. Much like the banks,Prodigy targets personal computer users (with modems) with extensivevideotext service (e.g. airline reservations, and home shopping). Unlikethe banks, however, bank services are secondary and Prodigy hopes tooffset some of its high costs with advertising revenues. Even if Prodigysucceeds, its services are aimed at a high-end, technology-user--not thebroader market comprising the majority of bank customers.

Telephone banking operators have recently begun to allow customers topay bills from home. Some such telephone billpaying systems involvevoice response technology to provide automatic handling of limitedcustomer financial transactions (thus eliminating the requirement forhuman operators to answer and handle customer calls). Severalindependent telephone billpaying services have emerged (e.g. Checkfreeand Merchants Network), but most billpaying services are offered byindividual banks. Recent voice-response technology advances have enabledtelephone banking and billpaying to become the banking industry'sfastest growing retail product. Payments Systems, Inc., a leadingelectronic funds transfer consulting firm, estimates that 5-7 millionU.S. households use telephone banking in 1988 versus approximately 2million in 1985.

Nonetheless, telephone billpaying has serious limitations because of itslack of a visual interface (i.e., display). Telephone voice responsesystems only permit the presentation of very limited, simplealternatives. Sophisticated service offerings are not practical becauseof their reliance on complex branching alternatives which can not beeasily remembered by users. As a consequence, telephone billpaying userseasily lose track of their place; confirmation and review of payments islimited; users need to keep track of payee code numbers on separatepaper lists; and user options such as scheduling payments becomeexceedingly complex and thus virtually impractical. Telephone billpayingservice providers have high cost structures and, despite advances invoice-response technology, telephone billpaying has serious inherentservice limitations.

Telephone banking is convenient but has inherent limitations which makebillpaying and other complex financial services very hard-to-use. ATMs,on the other hand, are very easy-to-use, but lack the convenience of atelephone.

ATM usage has grown dramatically in the past decade. There are nowapproximately 140 million cardholders in the U.S. Japan has over 135million ATM cardholders, and Europe has 122 million cardholders.Approximately 25% of U.S. households use an ATM cards or more times permonth. These cardholders have demonstrated a high degree of comfort withelectronic banking. These customers tend to be under 40, upwardlymobile, and convenience-oriented. See, for example,

Kutler, "Marketing Effort is Needed to Swell Ranks of ATM Users",Consumer Survey, American Banker pp 73-76;

"Survey of ATM Networks and Debit Card Users", The Nilson Report (1987Ed.); and

"Three-Quarters of Households to Use ATMs by Year 2,000", Bank Systemsand Equipment p 38 (September 1987).

While ATMs are very easy-to-use, they currently allow users to accessonly a limited number of bank teller services. A bank's own ATMs aretypically connected by direct line to the bank's data processing system.The bank's data processing system, in turn, communicates with a regional(or national) "ATM Network"--a specialized digital packet network whichcommunicates ATM and POS (point of sale) transactions among banks usingstandardized message protocols. These ATM networks and associateddigital switches permit someone using the ATM of one bank to access anaccount in another bank, for example.

ANSI and others have established standards on ATM digital messageprotocols and other features of ATMs. A more-or-less standard, genericATM interface has developed in the banking industry, making itrelatively easy for a user to use any ATM on the ATM network once has helearned how to interact with this more-or-less standard interface. Ofcourse, ATMs produced by different manufacturers may differ in keyplacement, number of keys, key legends, screen size, etc. However, therehas been a trend toward standardization so as to minimize userdiscomfort with using a "foreign bank" ATM.

Of course, a bank customer wishing to use the ATM network to conduct afinancial transaction typically has to travel to a nearby ATM (e.g., ata local bank branch). Moreover, most ATMs generally do not permitcustomers to pay bills or conduct other complex financialtransactions--typically limiting the user to withdrawals, accountinquiries, account transfers, and, if the ATM the user accesses is thatof his own bank, deposits.

It is known to utilize the ATM network to conduct financial transactionsother than in the manner discussed above. The following references aregenerally relevant to use of an ATM network/switch for processingvarious types of financial transactions:

ITS Develops SHAZAM Bill Payer For Consumer and Merchant Convenience",ITS Current, pp 3-5 (March 1988);

Levy, J., "The Delicate Balance of ATM Industry Standards", The EFTSourcebook, pp 35-38 (1988)

National Directory of Shared ATM/POS Networks 1987 Edition, TransDataCorp.;

Interregional Sharing Model of the Shared Network ExecutivesAssociation, pp 467-70;

Zimmer, "A Leading Analyst Investigates Whether the ATM Market HasReached Its Saturation Point or is Poised for Expansion", AmericanBanker, p 13, Vol. 152, No. 234 (Dec. 1, 1987);

Garsson, "NCR Universal Credit Union Claims A First with Home BankingServices", International Banker, p 10 (Aug. 24, 1983);

Anderson, "Electronic Funds Transfer is Reaching the Point-of-Sale;Banks, Retailers Look to EFT Transactions to Lessen Processing Costs,Increase Market Share", American Banker, p 32 (Jul. 28, 1982); and

"Electronic Networks Springing Up All Over: Systems Linking AutomatedTeller Machines, Point of Sale Devices are Established or Contemplatedin Several Areas of the Country", American Banker, p 2 (Mar. 19, 1982).

It appears from the articles referenced above that others in the pasthave explored the use of an ATM network/switch to route point-of-saleand/or billpaying data requests and transactions. For example, theNational Directory reference (see above) claims that four ATM networksprovide participants with home banking services (although this claim mayactually be false). The "Shazam" system, under development in Iowa,permits a consumer to pay bills to prespecified accounts using a bankATM or special purpose ATM type "billpaying terminal" located in abranch bank and communicating directly over the ITS ATM network. The MACsystem permits a PC-based home banking service provider to use thenetwork to perform limited functions such as balance inquiry and fundstransfers. Aggregated bill payments are transmitted to banks using theMAC network as a simple data carrier at the close of the banking day inbatch mode.

Some point-of-sale (POS) systems do exist which are capable ofautomatically generating debit requests and applying such debit requeststo an ATM network (e.g., to result in immediately debiting a purchaser'saccount). Specifically, it appears that some such POS systems include a"concentrator" central computer connected to local modems. The localmodems receive incoming calls over dialup telephone lines from remotePOS stations located at retail sites. When a purchaser makes a purchase,he provides a magnetic stripe card which is encoded with identity andaccount information readable by the remote POS terminal. The purchaseralso is required to input his PIN (personal identification number) forsecurity reasons. The POS station automatically dials the centralcomputer and transmits an identification of the retailer; purchaser bankand account information; and a dollar amount to be debited. The centralcomputer reformats the POS request into a standardized POS debit requestmessage which it transmits over the ATM network. The transmitted debitrequest causes the purchaser's bank account to be immediately debited,and may also provide a feedback message to the remote POS terminalindicating that the purchaser had an account balance exceeding thepurchase amount and that the purchase amount has been successfullydebited from the purchaser's bank account. Additional mechanisms causethe debited funds to eventually be paid to the retailer.

The following patents are generally relevant to prior dedicated homebanking terminals and associated systems/networks:

U.S. Pat. No. 4,634,845 to Hale et al

U.S. Pat. No. 4,689,478 to Hale et al

U.S. Pat. No. 4,694,397 to Grant et al

U.S. Pat. No. 4,305,059 to Benton

U.S. Pat. No. 4,341,951 to Benton

U.S. Pat. No. 4,625,276 to Benton et al

U.S. Pat. No. 4,536,647 to Atalla et al

The two Hale patents relate to a specific dedicated home bankingterminal and associated system. Grant et al broadly teaches a systemwhich integrates banking and brokerage services via a datacommunications gateway between the two systems. The three Benton patentsrelate to details concerning personal banking/financial transactionterminals. Atalla et al teaches a portable banking terminal includingdata encryption capabilities and discusses communicating over datacommunications lines with a data switch (see FIG. 1 and associatedtext).

The following patents relate to banking terminal securityconsiderations:

U.S. Pat. No. 4,390,968 to Hennessy et al

U.S. Pat. No. 4,525,712 to Okano et al

The following additional patents are of general interest as representingthe state of the art:

U.S. Pat. No. 4,454,414 to Benton

U.S. Pat. No. 4,578,535 to Simmons

U.S. Pat. No. 3,920,926 to Lenaerts et al

U.S. Pat. No. 3,652,795 to Wolf et al

U.S. Pat. No. 4,713,761 to Sharpe et al

U.S. Pat. No. 4,683,536 to Yamamoto

U.S. Pat. No. 4,678,895 to Tateisi et al

U.S. Pat. No. 4,594,663 to Nagata et al

U.S. Pat. No. 3,375,500 to Fowler et al

U.S. Pat. No. 3,970,992 to Boothroyd et al

U.S. Pat. No. 3,648,020 to Tateisi et al

U.S. Pat. No. 4,654,482 to DeAngelis

Most banks believe that remote banking is a good idea waiting for anacceptable, cost-efficient, easy-to-use delivery system. Most bankcustomers dislike the time consuming drudgery they devote every month topaying bills and conducting other banking transactions, and wish a lowcost, easier way existed to perform these transactions. Unfortunately,the prior art discussed above does not provide any practicalarchitecture for providing comprehensive banking services (includingpaying plural bills to user selected payees) in the home or office overstandard dialup telephone lines via an ATM network.

The present invention provides a solution to many of the problemsdiscussed above. In particular, the present invention provides apractical, cost-effective, workable system and method for deliveringbanking and other financial services (including billpaying capabilities)to remote sites such as customer homes and offices while avoiding thepitfalls encountered by home banking experiments of the past.

The present invention capitalizes on the convenience of the telephoneand the widespread familiarity with automatic teller machines. Previous"home banking" applications required a personal computer (PC), a modem,complicated software procedures and considerable training and/orcomputer knowledge. Home banking was thereby confined to the extremelysmall niche of sophisticated PC users. Now, with new technology and anestablished base of 140 million ATM cardholders, the present inventioncan reach a large market with low cost services:

The present invention serves this market by providing a low cost(possibly free) ATM-like terminal, which preferably uses low-costApplications Specific Integrated Circuit (ASIC) and surface mounttechnology for low cost and high reliability;

The present invention targets remote banking service to 50 million U.S.households owning ATM cards, 21 million of whom show a high degree ofcomfort with electronic banking;

The present invention preferably utilizes ATM and telephone companydigital communications networks, thus avoiding a large upfront fixedinvestment and ensuring low operating costs;

The present invention system costs are supported by sharing processingsavings with banks, payees and advertisers (who target ads to usersbased on spending patterns).

Briefly, the present invention provides dedicated telephone-basedbanking terminals to users for home or office use ("home banking"). Anasynchronous communications link is connected to a telephone companypublic data network (or other digital packet network) between the remoteterminal and a central computer system operated by the service provider.A central computer system analyzes and processes the user paymentinstructions--typically processing a user's request for many discretefinancial transactions at one time. The central computer storesinformation about these transactions in a database it maintains, andthen generates electronic funds transfer (EFT) requests which itcommunicates to the user's bank via an ATM network/switch. For example,the central computer system may debit the user's account at his bank(e.g., via a POS debit message passed over the ATM network) andelectronically transfer the funds to a holding account or bank. Thecentral computer then distributes the funds (bill payments) to thepayees requested by the user.

ATM networks have been used for ATM use and more recently forpoint-of-sale (POS) uses. When combined with new PDN service as in thepreferred embodiment of the present invention, ATM networks permitdevelopment of a market at minimal upfront, fixed cost and very lowvariable operating costs. The system provided by the preferredembodiment of the present invention basically acts as a conduitconnecting bank depositors with their bank through telephone companygateways and ATM networks. The service provider need not build its ownnetwork, and banks need not install new communication lines or software.

Since ATM networks have in the past usually provided only limitedservices (e.g., withdrawal, deposit and account inquiry, and morerecently, point-of-sale transaction handling), the present inventionoffers a new use of the existing ATM networks to provide transactionsnot previously supported by the networks and also provides a new centralcomputer/communications system performing new functions--in addition toproviding a linkage never before existing between two networks (i.e., adigital packet network accessible through dialup telephone gateway, andan ATM network) for the purpose of home banking.

Payments can be processed immediately and made using EFT means(automated clearinghouse, direct deposit in concentrator accounts,point-to-point, etc.) through payment network. Certain EFTs areprocessed through the originating ATM network (or though another ATMnetwork). Payments not made electronically are sent by post in the formof a check and payor invoice information list ("check and list"). Inaddition, the central computer system can transmit to the user's bankthe names of payees and other Federal Reserve Regulation E informationthrough the ATM network using POS formats. This permits the customer'sbank to print a unified statement listing the billpaying transactions aswell as normal bank transactions (e.g., deposits, debits, and ATMwithdrawals).

Thus, once entered into the system a user terminal is linked in thepreferred embodiment through a gateway to a public data network (PDN)service of a regional telephone company. Telenet and other PDN serviceshave been available for years, and these services remain competitive tothe regional telephone companies on an interstate basis. However, thedata packet price of local PDN services is usually lower for regionaltelephone companies (because the cost of their networks is amortizedover many users and alternative uses.)

The preferred embodiment preferably includes compact inexpensive remoteuser terminals capable of interfacing with standard dial-up telephonelines. One version of the preferred embodiment terminal is compact insize (3.75"×8"×1.75"), portable and simply connects to the user'stelephone jack. A second version of the terminal has a telephone handsetand associated electronics permitting the consumer to use the device asa terminal or as a conventional telephone. No hardware or installationexpense is required. Users operate the terminal intuitively, and usersneed not have prior computer experience. Since the present inventiontargets ATM users, the terminal is designed to interact with users in amanner similar to ATM user interaction.

Users preferably activate the preferred embodiment terminal by simplyturning it on. The terminal automatically dials a central processorsystem over dialup telephone lines. Users are preferably welcomed in thename of their own bank. They may gain access to services by identifyingtheir account from a menu of authorized household users, then enteringtheir bank ATM personal identification number (PIN). A built-in securitydevice is preferably provided to afford high level security to the user,and the terminal has the capability to transmit encrypted data.

Users preferably receive and view messages through a four line (e.g., by24 or 30 character) liquid crystal display (LCD). Instructions arecommunicated through a backlit display adjacent to the LCD. Messages arecommunicated at high speed (e.g., 1200 baud) over dialup lines. Theterminal takes advantage of significant human factors research anddevelopment performed by the U.S. Department of Defense and adopted bymajor ATM producers. By positioning selection ("soft") keys next tooptions displayed on the screen, users can more easily understand andquickly respond to instructions. Users thereby communicate bysingle-stroke responses to choices displayed, and the service providerhas much greater system flexibility with which to format screens andexpand services.

Moreover, the preferred embodiment terminal and associated userinterface to some extent mimics the terminal/interface provided bystandard ATMs already in use by millions of bank customers. Thepreferred embodiment thus eliminates or reduces the level ofapprehension many users might harbor toward learning a new terminal andinterface. When a typical new user first uses the terminal provided bythe present invention, he intuitively knows how to navigate through theuser interface/menu structure because the user interface is (at leastsuperficially) similar to that of ATMs he has used in the past. Ofcourse, the user interface and terminal provided by the presentinvention offer far more functionality than is available through astandard ATM, and in fact are extremely different from the standard ATMterminal/interface. However, the user's initial impression is perhapsthe most important and the typical user's first impression to theterminal provided by the present invention is that it is "like" an ATMand can be operated intuitively without reading a user manual andwithout any steep learning curve. The primary market for the servicesprovided by the present invention is 21 million highly active ATM userswho will view the invention as a convenient, comfortable extension ofcurrent ATM services. The services may also appeal to certain non-ATMusers, who will be attracted to the expanded services (e.g., billpaying)provided by the present invention.

The major emphasis in designing the terminal and its support system isservice and ease-of-use. This has been achieved by adopting a number offeatures contained in the popular ATM machines employed by banks, suchas for example:

1) Keyboard and Screens: The latest ATM machines contain simpleuncluttered keyboards usually consisting of an alpha/numeric keypad, acancel key, enter key and a number of "soft" (i.e., programmable)selection keys adjacent to the screen which have no fixed function. Thefunction of these soft keys is described on the screen and is related toservice that is being provided. Older machines tend to have multiplededicated function keys that perform one specific function. The usermust push the proper function keys in the correct sequence to completethe transaction in which he is interested. These keyboards tend to becluttered and confusing. The displays associated with this type ofkeyboard are usually limited to several lines of text. The dedicated keykeyboard design approach is necessary because the limited size of thedisplay precludes the presentation of multiple alternatives among whicha user may select. Newer machines have larger video displays consistingof from four to eight lines and "soft" keys that fulfill differentfunctions depending on information provided on the screen. Users arepresented with multiple choices and asked to select the desiredalternative. The user pushes the "soft" key that corresponds to theselection he wishes to make. Similar to the newer ATM machines, theterminal provided by the present invention contains a four line by, forexample, 24-character LCD display (many ATMs use video displays), four"soft" keys, a cancel key and a numeric keypad. In addition, theterminal provided by the present invention contains a HELP key and twoscreen control keys labeled PRIOR and NEXT. Unlike ATM machines a userwho needs assistance can obtain it regardless of "where he is" in thetransaction process by pushing the HELP key. Contact sensitive helpprovides explanations regarding the transaction in which he is involved.The screen control keys permit the user to scroll forward and backwardwhen reviewing lists. Using the NEXT key also permits movement from onescreen to the next at the user's pace. The CANCEL key permits the userto correct erroneous input or back out of certain transactions when hehas mistakenly chosen an alternative.

2) Security: The ATM establishes a user's identity by requiring a cardand the use of a personal identification number (PIN). The terminalprovided by the present invention uses a slightly different approach inthat no card is required (although in at least one configuration a cardmay be used if desired). The terminal is generally in a more securelocation than is an ATM machine. At SIGNON the terminal transmits aunique number that identifies a particular household. The individualselects his name from the authorized household list. He is thenrequested to enter his PIN in much the same manner as with an ATMmachine. The data transmitted from the terminal is encrypted, providingsecurity against line tapping or theft of the line. An ATM uses a bankcard to determine who is signing on the machine; in contrast, inaccordance with one aspect of the present invention, terminal possessionis used as an indication of one of several users in a household.

3) Look and Feel: The newer ATM machines are menu driven, the user ispresented with a number of alternatives and he selects the one he wishesby using "soft" keys. This is preferable to the user having to follow alist of steps coordinating screen instructions with different dedicatedfunction keys on a nearby keyboard. There is less distraction andconfusion when the user is provided alternatives on the screen. He canbe given assistance upon request when he is uncertain. There is nolimited reading of keycaps or coordination of key colors or reading ofsequential instruction lists posted on the machine. In a similar fashionthe terminal provided by the present invention is menu oriented. Theuser can get to his desired service quickly (generally with selectionsfrom 1-2 levels of menus). The combination of "soft" keys and menubranching provides a look and feel very similar to an ATM with which heis comfortable and experienced although the terminal provided by thepresent invention also provides several additional important featureswhich provide increased functionality.

4) Services: The ATM primarily provides balance inquiry, cash withdrawaland check deposit accompanied by a receipt. Some ATMs permit limitedbill payment and last date of deposit and withdrawal. Instead ofprinting out a receipt like an ATM, a user of the terminal provided bythe present invention receives a statement from his bank at the end ofthe month. In addition, it is unlike an ATM in that you generally cannotreceive money or make deposits through the terminal (unless anadditional interface to a debit card or "smart card" is provided). Theterminal user is, however, able to pay all bills (present and future orpay periodically), transfer funds (today and in future), obtain balanceinformation, look forward and backward at statement activity (payments,deposits and transfers) transfer funds among accounts and banks, obtaininformation on bank services and rates anywhere there is a standardtelephone RJ-11 jack. With the addition of an alpha keyboard (which maybe an expansion feature) the terminal can provide E-mail and otheralpha-dominated services.

5) Personal Service: The terminal provided by the preferred embodimentof the present invention is compact and portable and is available foruse twenty-four hours a day. The list of payees the user selects can beanyone, not a preselected list as with the few cases where users paybills from an ATM. The services are available when the user wants, wherethe user wants. His billpaying time is reduced and he need not contendwith stamps, check printing fees, envelopes, and postal delivery.

6) Network Configuration: The ATM machine is usually connected to abank's computer via telephone or hard line. Accounting information isprovided by the bank's computer. Transactions that must be passed toother banks are transmitted through the ATM network. Those ATMs thatpermit billpaying inventory the bills that are to be paid during the dayat the ATM machine and are then posted after the close of the bankingday by the bank. The ORL system passes bill payments directly throughthe ATM interchange (in the form of point-of-sale transactions) fordebit and credit of accounts on a real-time basis.

To use billpaying features, customers provide the service provider inadvance with a list of payees (names, account numbers, addresses). Atypical household (owning an ATM card) writes 26 checks per month andthe list might, for example include payments for:

utilities--telephone, gas, water, electricity, cable TV;

residential--rent, mortgage, home, insurance;

automotive--gas credit card, auto insurance, auto loan;

credit card--AMEX, Visa, Master Charge and others;

retail--major department stores;

financial--installment loan, taxes, stock broker fees;

medical--physician, dentist, health insurance;

business--office parking fee, newspapers, magazines; and

miscellaneous--child care, tuition, church, vacation home, domesticemployees, etc.

Users may review past payments and schedule future payments (e.g., timedto meet anticipated funds availability such as a paycheck or checkdeposit). Users may also have the system provided by the presentinvention automatically pay fixed, recurring payments, such as rent,mortgages, and installment loans.

The preferred embodiment of the present invention processes informationtransmitted through the PDN using a fault-tolerant central processor toensure system integrity. Once the system provided by the presentinvention processes user payment instructions, it communicates with theuser's bank through a regional or national ATM network. Regional ATMnetworks (which are usually shared banking cooperatives) have beendeveloped to permit bank customers to access any ATM in their localarea. Users are no longer tied to their own bank's ATMs. The Cirrus andPlus ATM networks offer the same service on a national basis by linkingrequired ATM networks. The ATM network application provided by thepresent invention preferably requires no new hardware or softwaremodifications to ATM communication systems. And, very importantly,unlike other home banking systems (which require specialized software orautomated clearing house capability), the present invention requireslittle or no new software or operating procedural changes at a user'sbank.

Using an ATM network, the service provider pays customer bills by firstdebiting the user's account at his network bank--preferably by sending aPOS debit message over the ATM network. Such standard POS messages notonly permit the service provider to pass payee or other information overthe network to the user's bank for use by the bank in generating aunified monthly statement, but also provide an automatic accountinquiry/balance check function (so that the user does not overdraw hisbank account inadvertently). Funds are transferred through the ATMnetwork to the service provider's holding bank (or a clearing accountmaintained by the service provider in the user's bank). Payments arepreferably processed immediately electronically, where feasible, eitherimmediately or "warehoused" for a short time for transmittal with otheruser payments to a single payee. Otherwise bills are paid by papercheck.

Electronic payments can be processed through an Automated Clearing House(ACH) system, (e.g., Federal Reserve) directly to a payee(point-to-point), or to the payee's bank (directly or indirectly throughan ATM network or other remittance channel). In recent years, payeeshave become more receptive to working with electronic paymentsprocessors. Aside from minimizing a payee's processing costs and float,the present invention offers payees more predictable cash flow, lowerreturns (bad checks), and accounting and bookkeeping advantages relatedto consolidated payments.

The invention provides some additional benefits to payees. By processingcustomer bills as POS debits, liability for payment immediately shiftsfrom the service provider to the ATM network (or bank). Thus, theservice provider can advance funds to payees immediately with thecomfort that the advance will be covered on the next business day by thecustomer's bank or the ATM network. This reduces the payee's float by1-2 days versus conventional electronic billpaying systems. Secondly,payees may hold remittance accounts at banks who are members of the ATMnetwork. Debited funds and billing information may be sent directly tothese accounts. Payees who may not otherwise have the capability toaccept electronic payments may gain that capability. This reduces thepayee's remittance processing costs and permits the bill paying serviceprovider to make fewer, costly paper-based payments.

The cost of processing payments is relatively low in terms of equipmentand communication costs. Most costs are incurred in responding to userinquiries, correcting payee posting errors, maintenance of payeedatabases, and coordination between users, payees, and their banks.Higher costs are incurred by payments made by paper check, althoughthese costs are mitigated by interest earned on float due to postaldelivery time.

Other innovative features provided by the present invention include:

A new type of inexpensive ergonomically designed user-friendly dedicatedhome banking terminal including for example a four line LCD display withassociated control buttons "pointing to" the display lines for selectionof displayed options and auxiliary "Select One", "Or", "Change Screen","Enter Number" LED illuminated command prompts that are turned on andoff by the central computer system as needed.

Advanced "ATM-like" terminal layout:

Four line by 24 character liquid crystal display;

Four adjacent selection (i.e., "soft", programmable) keys directlyreferencing the display to be used for selecting alternatives;

Two function keys to provide on demand help and cancel functions;

Twelve alpha/numeric telephone-type keypad for numeric input and laterfor limited alpha input plus the "#" and "*" for later communicationsapplications and compliant with present telephone equipment standards;and

Two screen control keys that permit scrolling of the screen forward and

backward when permitted by system software.

Two level access security consisting of a unique terminal identification("signature") automatically transmitted upon establishment of theasynchronous communications link and an ATM type PIN number entered bythe user for system verification.

Onboard PIN and data encryption (DES or other standard) provided by ROMresident random number generation algorithm activated by a seedmaintained in RAM and a real-time clock.

LED backlit instruction panel adjacent to and working in conjunctionwith the active LCD display controlled main system software.

Dual purpose terminal operating as a data entry and display device andalternately, as a push button (tone/pulse) telephone communicationsset--including a common keypad used for tone generation for telephonecommunications and for data entry.

A dual isolated circuit keypad containing a double contact low costswitch to activate two unrelated circuits as input to the microprocessorand the telephone tone generator.

Data terminal that automatically transmits tone blocking signal toprevent intervention by call interrupt service.

The visual interface, flexibility and ability to recall information thatpermits the present invention to enjoy significant demand for automatedbillpaying without a telephone's limitations.

Look and feel of the software-user interface in coordination with a 4×24LCD display and selection and control keys to provide rapidcommunications of financial transaction information to main computersystem.

A terminal device that can act as a pass-through of analog voice signalto an externally attached on internally provided telephone oralternately transmit data (asynchronously).

A terminal device operating at low power levels permitting the tricklecharge of internal storage batteries from a telephone line source.

A terminal device that can store numerical data and transmit from amemory buffer upon command from an internal microprocessor.

A terminal device employing a 96 (up to 120) character LCD displayingthe amount of information capable of being contained in a single common128 byte packet data network packet.

The terminal is able to transmit a periodic randomly generated code tothe main system. The main system is able to verify that this numericcode is correct and assure that terminal communication link security ismaintained.

The terminal is compact, 8 inches wide by 5.75 inches and 1.75 incheshigh with the telephone handset. The compact non-telephone model is 8inches wide by 3.75 inches deep by 1.75 inches high. The compact modelcan easily slip into a pocket or briefcase, and is approximately 53cubic inches and weighs less than one pound.

The compact portable terminal contains two RJ-11 jacks so that atelephone line can be connected to one and a telephone to the otherthereby permitting use alternatively as a terminal or telephone.

A terminal with an internal data bus that will permit direct edgeconnect retrofitting of an alphabetic keyboard and/or card swipedevice;.

A system architecture connecting asynchronous, remotely located (home oroffice) dedicated purpose terminals (telephone and/or data) passingthrough asynchronous gateway onto a packet data network to afault-tolerant computer which is in turn linked to a single bank orgroup of banks using the bank's ATM interchange network for the purposeof bill payment and funds transfer and balance inquiry and activitystatement.

A system architecture connected to a network of electronic switchesand/or payees.

Use of an online computer which processes customer bill payments andpasses payee names and account information through the ATM interchangenetwork to a user's bank for posting to his monthly statement;

A system architecture that permits immediate credit of funds to theservice provider (upon debit authorization against the user's account,liability for payment of funds passes immediately to bank andinterchange network).

A system architecture that permits a combination of information access(account balances, account transactions) plus settlements (posting,reconciliation and clearing of funds).

Extraction of bill payer and payee information for demographic andmarketing analysis and retention in a database.

Maintaining such a database of billpaying information and extractingdemographic information from this database for use in targetingadvertisements or messages (the advertisements can be sentelectronically to each home banking user each time he "signs on" histerminal and/or distributed in other ways such as mass mailings which donot violate user confidentiality).

Analysis of bill payer payment patterns for the purpose of directingonline advertisements or messages targeted to differentiated groups ofusers.

A terminal screen which permits targeted advertising (or messages)without disclosing the user's name or other confidential information tothe advertiser (until the user requests disclosure or permits it).

A terminal oriented system that permits an immediate customer responseto targeted, displayed advertisements (or messages), whose responses arethen transmitted online or in batch mode to the advertisement sponsor.

A methodology of debits and credits for transferring of funds betweenbanks using online remote terminals communicated through the ATMinterchange network.

A methodology for debit of bill payments using online, remote terminalscommunicated through the ATM interchange network.

A methodology for use of an ATM interchange network for payee credits onbills.

A remote terminal oriented system directed at the ATM user populationfor home, office or other remote location bill payment, funds transferand account review.

Deposit oriented financing for a remote terminal based system for billpayment, funds transfer and account review; and

A cash incentive program for bills paid through a remote terminal basedsystem for bill payment, funds transfer and account review.

The present invention extends the convenience of popular automatedteller machine (ATM) type service to user (alternatively referred to ascustomers or consumers) homes, offices and other locations. The presentinvention provides a highly efficient payments system that offersconsumers the following advantages and features:

a low cost (possibly free), easy-to-use ATM-like communication terminalwhich is portable and simply connects to a telephone;

an incentive for every bill payment made through the terminal;

additional savings from postage, check printing, envelopes, and othercosts for each payment made through the terminal;

convenience, privacy and estimated time savings of 75% from the drudgeryof billpaying.

The added benefit of electronic funds transfer, banks and others gain asmuch as 40% processing cost savings and a new vehicle for remotedistribution of services.

To attract volume, the service provider may price services to allowusers to save money. The present invention provides the possibility ofbroad market distribution by providing users with a low cost (possiblyfree), familiar ATM-like terminal. In addition to being provided with alow cost or free terminal, users may save $0.30 in postage, check andother costs for each payment made electronically via the system. Thistotals to $7.30 per month savings for the average ATM household writing26 checks a month. A service provider may therefore charge up to $7.80per month and still permit the user to save money.

More important than cost savings, however, is the vast amount of timethe invention saves its users. Unlike PC's, telephones and priorterminals, the design of the present invention enables the users tointuitively master the terminal without relying on written instructions.Furthermore, the operations and coordination of system components in theform of modems, communications protocols, new security codes, andoperating software is obviated. The present invention relieves a commonfinancial headache--the time-intensive drudgery of billpaying. Thesystem provided by the present invention is a quick, extremelyeasy-to-use alternative to conventional payments. Initial testingindicates that users can pay bills in 25% of the time needed to paybills conventionally. Users may preferably receive a unified monthlystatement (from their bank) which consolidates and lists terminal-basedtransactions with conventional banking transactions (e.g., checks, ATMcash withdrawals, deposits, etc.).

Early home banking efforts discovered that users liked using the systemsto pay bills. They had only limited interest in other bank and videotextservices, so the present invention has reduced its delivery costs byspecializing in billpaying. While the present invention providesbillpaying services, customers may also use the system to better managetheir money. More sophisticated active users may better manage theirmoney by, for example, checking their account balances, viewing paymentrecords, transferring funds between accounts, future dating of bills andfunds transfers, and requesting other bank services. Future dating ofbills minimizes users float, and users may future date funds transfersto maximize interest bearing balances. Transferring funds between banksis possible with immediate debit or credit within one day (dependingupon the ATM network clearing procedures). The present invention thusprovides a terminal designed to accommodate additional financialservices in the event that users or banks demand (and are willing to payfor) more services. These may include comparative mortgage and CDquotes, tax deduction summaries, loan applications, electronic billing,third party billing, family budgeting tools, tax planning, and insuranceservices. Limited alphabet-based services (e.g. telephone directory) arealso feasible with the terminal of the preferred embodiment and theterminal has the facility to add on an alphabetic keyboard.

By displacing paper checks and employing payee information for marketingpurposes, the present invention offers significant benefits to the majorparticipants in the payments system:

Banks (and other financial institutions) avoid the cost of processingand returning checks and funds transfers. Fully absorbed processingcosts range from $0.50 to $1.00 per check (marginal costs vary withvolume). The present invention can save banks a substantial amount perpaper check displaced.

Payees (such as utilities, mortgagors, etc.) avoid paper processingcosts and improve cash flow. Typical remittances take 5-8 days to arriveby mail and cost from $0.15 to $0.75 per payment. The present inventioncan provide a small charge to payees for each electronic payment anddeliver payments in 2-3 days. This saves payees money per payment andcompares favorably in cost to bank lockbox services.

Marketers (such as retailers and banks) can better advertise (ormessage) through the terminal. By analyzing users' payments, the presentinvention can target advertising or messages to users for 5-7 secondsafter they SIGNON. Users may then respond if they want more information.Targeted (but low readership) direct mail costs advertisers $0.45-$1.00per piece. Pricing for confirmed leads starts at $5 and increases withthe products value. This aspect of the present invention will offeradvertisers significant benefits in terms of flexibility and costsavings. The terminal's screen for advertisements permits the serviceprovider to target advertisements to groups of users without disclosingthe user's name (and confidential payment data) until the user soindicates his permission (by requesting more information from theadvertiser).

Payments processors earn interest on user payment float. The presentinvention debits a user's bank account on the date of payment. Thepayment is processed immediately, but interest is earned on the funds(float) until cleared. When the system of the present invention cannotpay electronically, it earns interest on float for 5-8 days. A serviceprovider will prefer to process payments by low-cost electronic means,however, providing better money management services for customers.

A major obstacle in building any volume-oriented business is the upfrontinvestment required to reach a critical mass of customers. The presentinvention minimizes this investment by capitalizing on existing systemsand customer bases. The present invention piggybacks on the evolving ATMand regional telephone company communications networks.

Most ATM networks are bank-owned cooperatives and have excess capacity.These networks are likely to welcome the additional business provided bya system in accordance with the present invention. By working with ATMnetworks, the system provided by present invention becomes a utility forbanks--not a threat to banks. For example, once admitted on to thesystem, users can be welcomed in the name of their bank. Users alsoreceive a single account statement from their bank, unifyingterminal-based activity with conventional banking transactions and checkpayments. Back-office check processing and funds transfer economies canalso be priced to provide costs savings to banks. Participating bankscan be encouraged to advertise over the system provided by the presentinvention system at sharply reduced rates while back-office savings fromreduced paper check volume develops. The advertising medium provided bythe present invention offers banks an extremely powerful "cross-selling"tool (a critical key to success in retail banking which involvesincreasing profitability by increasing the number of services sold to asingle customer).

The present invention thus provides a highly advantageous system whichoffers an attractive proposition to a variety of participants in thepayments system. Users of the invention save time and money and can paytheir bills and obtain other banking services wherever there is atelephone jack. Banks save back-office realize an efficient means toservice their customers. Bank owned ATM networks generate volume andearn fees. Payees improve cash float and save on costly processing ofpaper checks. Advertisers gain a powerful, low-cost marketing tool.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages will become better understood bystudying the following detailed description of presently preferredexemplary embodiments in conjunction with the attached APPENDIX (whichis incorporated by reference herein) and the sheets of drawings, ofwhich:

FIG. 1 is a block diagram of a presently preferred exemplary embodimentof a financial services distribution system in accordance with thepresent invention;

FIG. 1A is a detailed schematic block diagram of the FIG. 1 CPU.

FIG. 2 is a block diagram of revenue sources provided to the operator ofthe FIG. 1 system;

FIGS. 3 and 4 are elevated respective views of alternate embodiments ofa presently preferred exemplary remote terminal in accordance with thepresent invention;

FIGS. 3A-3E schematically depict different prompt combinations providedby the FIG. 3 terminals.

FIGS. 5A and 5B together are a schematic block diagram of the FIG. 3terminal;

FIGS. 6A-6C are different views of an exemplary keypad contactarrangement incorporated within the FIG. 3 terminal;

FIGS. 5C 7A-8B are schematic flow charts of exemplary program controlsteps performed by the terminals shown in FIGS. 3 and 4; and

FIGS. 9-22 are schematic flow charts of exemplary program control stepsperformed by the CPU shown in FIG. 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a schematic block diagram of a presently preferred exemplaryembodiment of a financial services distribution system 50 in accordancewith the present invention. System 50 includes a fault-tolerant centralcomputer system 52 (hereafter referred to as "central computer"), aplurality of remote terminals 54, a digital packet network (e.g.,"public data network") switch 56 ("PDN switch"), packetassembler/disassembler 58 and associated asynchronous communicationsinterface 60, and a dialup telephone network 62 selectively connectingremote terminal 54 to the communications interface.

Data is communicated between remote terminal 54 and central computer 52through the PDN switch 56, the packet assembler/disassembler 58, thecommunications interface 60, and dialup telephone lines 62.

In the preferred embodiment, PDN switch 56, packetassembler/disassembler 58, asynchronous communications interface 60 anddialup telephone network 62 are entirely conventional and are preferablyoperated and maintained by a local or regional telephone company. Switch56 may comprise, for example, a conventional public data network of thetype which communicates packets in CCITT X.25 protocol between centralcomputer 52 and packet assembler/disassembler 58. Similarly, packetassembler/disassembler 58 and asynchronous communications interface 60may comprise conventional telephone company operated subsystems whichconvert the X.25 packet protocol existing on the PDN network intoconventional asynchronous data format (e.g., with seven or eight databits, a start bit, a stop bit and conventional error checking fields).

Asynchronous communications interface 60 initiates and answers dialuptelephone communications with remote terminals 54. Thus, remoteterminals 54 interface with the remainder of system 50 using standardasynchronous protocol, central computer 52 interfaces with the remoteterminals using standard X.25 protocol, and conversions between the twoprotocols (as well as distribution of the signals generated by thecentral computer to specific remote terminals) is handled by theconventional PDN switch 56, packet assembler/disassembler 58 andcommunications interface 60 provided by the telephone company in thepreferred embodiment.

Central computer 52 also interfaces with banking institutions and withother financial institutions 64 through the existing conventionalautomatic teller machine (ATM) interchange switch 66 (referred to hereinas the "ATM network"). The ATM network is capable of communicating ATMtransaction messages as well as point-of-sale (POS) messages in aconventional manner using standard message formats. As explained above,ATM switches 66 communicate data in a specific, conventional interchangeformat between member banks or between automatic teller machines (ATMs)and member banks 64. In the preferred embodiment, central computer 52 isconnected to ATM switch 66 (e.g., via one or more bisynchronous 9600baud communications lines) and communicates digital signals to the ATMswitch using standard bisynchronous (e.g., point-to-point, SNA, etc.)communications protocol. Thus, in the preferred embodiment, centralcomputer 52 "looks like" an ATM or POS node connected to the ATM networkand associated switch. Central computer 52 may generate account inquirycommands, commands to debit and credit accounts, and the like--just aswould a bank's computer serving its ATMs or as would a stand-alone ATMor POS terminal. The ATM interchange switch 66 processes such ATMcommands generated by central computer 52 in the same way that theyprocess commands generated by ATMs. Although the ATM interchange is ATMoriented, it is able to serve other terminal devices. For example, theATM interchange communicates with retail POS terminals which candirectly debit and credit a customer's bank account in payment forpurchases.

It is also possible to provide direct dialup lines for communicatingdata between member banks 64 and central computer 52 (e.g., usingstandard communications protocols agreed upon by the bank's dataprocessing system and by central computer 52). Use of the ATM switch 66and associated network to carry ATM/POS commands generated by centralcomputer 52 avoids the need to provide any software modifications orother overheads within the member banks' data processing systems.Furthermore, use of the ATM switch 66 permits use of the network fundsclearing process.

Central computer 52 also electronically communicates with additionalremote data processing systems such as the Federal Reserve ACH 72 (e.g.,via a Federal Reserve Bank data processing system 74), debit networks76, wholesalers/remittance processors 78, direct payee computer systems80, third party information providers 82 and advertisers 84. Suchadditional communications may be over dialup telephone lines ifdesired--or other special communications arrangements/protocols (e.g.,magnetic tape transfer or the like) may be used depending uponparticular applications. The link between cental computer 52 and theFederal Reserve ACH 72 permits payee commands to be electronicallytransferred to other banks using the existing Federal Reserve electronicfunds transfer system. The link with wholesalers and remittanceprocessors 78 permits the payment of bills to a remittance center who inturn pays payees. The direct computer payee link 80 allows centralcomputer 52 to contact individual desired payee computer systems anddirectly effect download of payment related data (e.g., pursuant to adaily "clearing" process). The link to advertisers 84 may be used totransfer advertiser copy between the advertiser and the central computersystem and to pass back to the advertiser the names of those customerswho request information in response to advertisements.

FIG. 1A is a schematic block diagram showing central computer 52 insomewhat more detail and also schematically depicting exemplary softwaremodules used by the central computer to perform financial transactionfunctions. Central processor 52 in the preferred embodiment is afault-tolerant mainframe computer of conventional design including, forexample, multiple redundant processors, a dual interprocessor interbus,a dual-ported controller, and multiple redundant power supplies toensure against data loss. Through use of this conventionalfault-tolerant architecture, the failure of one processor or componentdoes not stop processing but rather merely decreases system throughput.Additional peripheral equipment (e.g., tape drive 88, check printer 86,conventional mass storage device 84, and conventional communicationsinterface/multiplexer 82) facilitate communications and billpayingtransactions.

Central computer 52 is programmed (i.e., with software modules stored onmass storage device 84) to perform various billpaying and otherfinancial functions and to distribute billpaying and other services toremote terminals 54 on demand. In the preferred embodiment, the softwaremodules executed by CPU 80 are in large part entirely conventional(within new linkages between them) and perform, among other operations,conventional banking, ATM network communications network interfacing,database maintenance, etc. However, certain new software controlledfunctions (e.g., the terminal handling and associated functions, and theinterfaces between the terminal handling and other, conventionalsoftware controlled functions) have been provided in the preferredembodiment to provide home banking and billpaying functions notpreviously available.

As mentioned above, many or most of the software-controlled operationsperformed by CPU 80 in the preferred embodiment are conventional andwell-known in the banking industry. For example, it is conventional andwell known to communicate standard ATM and POS messages between acentral computer and an ATM network using conventional off-the shelf ATMand POS software, and central computer 52 in the preferred embodimentutilizes such conventional software to generate and communicateappropriate messages over the ATM network 66. Conventional bankingsoftware packages exist which perform a variety of exceedingly complexbut entirely conventional functions (e.g., maintaining audit trails toensure transaction reliability, maintaining user account and venderfiles, providing clearing information at night, etc.) and the preferredembodiment central computer 52 executes such conventional bankingsoftware modules to perform such standard functions. Conventionaldatabase handling functions are also typically integrated into bankingand POS software modules to maintain customer information.

The following is a brief description of exemplary general functionsperformed by the various software control modules provided within CPU 80shown in FIG. 1A.

The manager 80A schedules and coordinates the flow of transactionsthrough the various system modules. As flow control it sends thetransactions to the appropriate modules for processing and control ofinteractions with the external environment.

The device (terminal) interface 80B enables the system to communicatewith user terminals and the system CRTs. The device interface 80Bformats terminal-bound messages for transmission to the terminals 54. Inaddition, the device interface 80B is responsible for error processing,starting and stopping transaction response timers, updating any fieldswhich are maintained in the user terminal, decrypting and logging oftransactions. A detailed description of the terminal interface 80B willbe provided shortly.

The routing module 80C permits efficient routing of transactions to theappropriate module for servicing.

The authorization module 80D is the means by which the system determinesthe customer identity (through the PIN and other values transmitted bythe terminal). User account number and PIN values are transmitted to theuser's bank (over the ATM network 66 in the preferred embodiment) forverification. When the authorization module 80D receives verificationfrom the bank the user is cleared for transactions.

The settlement module 80E (part of a conventional banking or POSsoftware system) is responsible for closing the current processing dayand starting the next. The settlement module 80E provides for flexiblecutover times for the network and payee institutions. In addition, thismodule updates databases files and initiates daily reports by thereporting module.

Reporting involves the calculation and reporting of debits and creditsand adjustments for the transactions performed on a daily and periodicbasis. In addition, system and network activity, reconciliation,interchange settlement and disputed transaction reports are generated.The reporting module 80F in the preferred embodiment is conventional andoperates in conjunction with a conventional database query program whichpermits analysis and specialized report generation concerning customertransaction profiles.

The update/refresh module 80G updates databases files following batchprocessing for a day in a conventional manner. Backup files aregenerated by this module. A sub-module also permits extracts of databasefiles to be generated and output to tape 88 or disk.

The banking module 80H is conventional and permits customers to paybills without writing and mailing checks, obtain account balances andconduct funds transfer between accounts. For bill payment the customer'saccount is debited for the amount of the payment, the payment medium iscreated (check, ACH tapes, internal transfers) and exception items aresegregated for review. The module 80H maintains customer database files,vendor files and transaction files. The banking module 80H providesfacilities for marketing information analysis, accounting/audit trails,and customer service reports.

The interchange interface module 80I in the preferred embodiment enablesthe fault-tolerant computer system 52 to interface with the interchangenetwork in a conventional manner. This module 80I converts internalsystem transaction information to a format that is compatible with thatof the network. In addition, a log is conventionally maintained of alltransaction communicated between the system and the network.

An important feature of the present invention is the use of aconventional ATM network and associated standard ATM and POS messageformat to facilitate financial transactions not typically supported bythe ATM network. As mentioned above, conventional ATM networks typicallyconnect bank mainframe computers and POS (point-of-sale) concentratorcomputers together.

For example, a user having a bank account in bank A (the "on us" bank)connected to the Internet ATM network may use the ATM machine of bank B(a "foreign" bank) to withdraw from his bank A account. The mainframecomputer of bank B generates, in response to the user's request via theATM message specifying the user's PIN (personal identification number),the user's account number, the user's bank and the amount to bewithdrawn. This ATM withdrawal message is then sent over the ATM networkand is received by the computer of bank A. Bank A checks the message forvalidity.(i.e., to make sure the PIN is correct), determines whether theuser has a sufficient account balance to honor the withdrawal request(the message processing thus provide an automatic account balancecheck), and then processes the request by posting a debit memo againstthe user's bank account (the bank A computer does not actually withdrawfunds from the user's account at this time, but will process the memoduring the posting and settlement process later that day). The bank Acomputer then sends a confirmation message back over the ATM network tothe bank B computer confirming that the user's account has been debitedand that at clearing time bank A will pay the funds to bank B. Based onreceipt of the confirmation message over the ATM network, the bank Bcomputer controls the bank B ATM machine to dispense the requested fundsto the ATM user.

An ATM "account inquiry" message also exists to permit the user todetermine the balance of his bank account(s). Similarly, an ATM "accounttransfer" message allows a user to transfer funds from one account toanother in the same bank (but typically does not permit the user totransfer funds between banks).

Similarly, a chain of retail stores may permit processing of so-called"debit cards" (like credit cards, but rather than credit being extendedby a lending institution to cover purchases, a debit card results in animmediate electronic debit of the user's bank account). A customerprovides the retailer with his debit card which the retailermagnetically reads (e.g., using a "swipe" type magnetic card reader).The customer is then asked by the retailer to secretly key in his PINinto a keyboard, and the retailer keys in the amount of the purchase. APOS debit request digital message is then transmitted either directlyover an ATM network (or indirectly via a dialup or dedicated telephoneline and a central concentrator computer) for receipt by the user'sbank. The POS debit request digital message typically contains theuser's bank designation and bank account designation; the user's PIN(which is typically encrypted); the name or other designation of theretailer; and the amount of the purchase. The user's bank computerreceives the POS debit request message from the ATM network, processesit for validity (i.e., valid PIN, valid account), ensures the user'saccount balance is in excess of the debit request, and then debits theuser's account (i.e., by posting a debit memo) and credits theretailer's account electronically (this typically requires the retailerto have worked out an arrangement with the particular user's bankbeforehand). The bank transmits a confirmation message to the POSterminal over the ATM network which, when received, assures the retailerthat the funds are available and have been transferred to his account.

POS credits are also possible using standard ATM network messages. If acustomer returns merchandise to a retailer that was paid for using a POSdebit, the retailer may initiate a POS credit transaction (essentiallythe same as a POS debit except that funds are credited to rather thandebited from the user's bank account).

Technically, some ATM networks handle POS debit messages and ATMwithdrawal messages differently in that the ATM withdrawal message isnot finalized until the end of day settlement process (that is, debitsare held in a pending status during a business day until finalreconciliation, settlement, and clearing and crediting of funds occursafter the close of a business day). POS debit messages on the other handresult in immediate settlement in real-time (i.e., the payees account isdebited immediately and liability shifts to the bank/ATM network toclear/collect funds at a later time). For purposes of the arrangementsdisclosed herein, both types of processes are referred to as "real-time"transactions since the resulting confirmation message over the ATM is ineffect a real-time electronic guarantee that the bank and/or the ATMnetwork will pay. In addition, "POS" and "ATM" type messages aresometimes referred to herein generically as an "ATM network transactionmessage", and such term is defined to encompass both types of messages.Some ATM networks are not capable of handling POS type messages, butrather process only the standard ATM messages.

The preferred embodiment of the present invention uses the types ofstandard messages described above to facilitate electronic billpayingand other financial transactions. For example, a funds transfer from anaccount in bank A to an account in bank B may be accomplished bygenerating a POS debit message directed to the bank A account and a POScredit message directed to the bank B account and by then applying bothof these messages to the ATM network. The service provider may pay billsby first determining the total amount of all of the bills to be paid atpresent, generating a POS debit message for application to the ATMnetwork (so as to debit the user's account by that amount and credit theservice provider's holding account by the same amount), and thendisbursing the funds (electronically or by paper) based on receipt ofthe ATM confirmation message. Account inquiry may be handled as astandard balance inquiry ATM or POS message or possibly as a "null" POSdebit message. One advantage of using POS debits/credits over ATM stylemessages is that the POS messages are longer and systems software isdesigned to provide sufficient space in the message to transmit the nameof the retailer and other Federal Reserve Regulation E information. Theuser's bank thereby takes a POS debit (with accompanying payeeinformation) and merges with the user's account file. Users therebyreceive their usual bank statement that unifies conventional bankingactivity with their home banking activity. The home banking serviceprovided need not send users an additional statement. The same resultcan be accomplished with a non-POS ATM message with a payee identifiercode located at the ATM switch or the user's bank.

Typically, an independent service provider may operate central computer52 and distribute terminals 54 as part of an ongoing businessindependent from the banking business. FIG. 2 is a schematic blockdiagram of the sources of revenue provided to the service provideroperating system 50. In order to make the operation of system 50economically feasible, the operator of the system must be able torecover equipment and development costs and also make an additionalprofit. FIG. 2 shows some of the sources of revenues to the serviceprovider operating system 50. First, users of remote terminals 54 maypay a relatively nominal charge (e.g., $4.00-$6.00 per month) for thecapability of paying bills electronically from their home. Users mayalso be asked to pay a deposit charge for the terminal which may then beused by the service provider to finance system expansion. The users'banks also are willing to pay a charge for each check or funds transferthey do not have to process. As is well known, a relatively high chargeis associated with processing each check (or funds transfer), andreduction in the number of debits/credits processed constitutes asubstantial savings to banks. The user's payees similarly may pay anominal charge for electronic payments and consolidated payments due tothe costs saved because funds are received quicker and processed forless. The service provider will also earn some interest on its float forpaper-based payments (i.e., funds debited immediately from users'accounts upon request for payment but not yet payed to the intendedpayee). Finally, system 50 may be used to distributeadvertisements/messages to users via the remote terminals 54--andadvertisers can be charged for each advertisement actually distributed.Furthermore, advertisers probably are willing to pay additional for theidentity of those customers that request information in response toadvertising. The present invention thus fills a marketing niche byproviding services to banks, users, payees and advertiserssimultaneously--and can generate revenue by charging each of theseentities an appropriate fee the value of the services provided (whilealso in certain cases earning interest on the float on the funds used topay bills). In addition to hardware, software and training limitations,conventional home banking systems have high cost structures. These costsmust be passed along to users--further inhibiting their demand. Theinvention permits low-cost delivery and a variety of revenue sourcesbeyond the user. User fees can be kept low--increasing demand.

FIGS. 3 and 4 are elevated respective views of alternate embodiments ofremote terminals 54 as shown in FIG. 1. As can be seen from FIGS. 3 and4, in the preferred embodiment, the terminals 54 are available in twodifferent types: a model which contains data entry and voice telephonecapability (including a telephone handset 100 and associated telephoneelectronics); and a smaller, pocket-size version (shown in FIG. 4) thatcontains no telephone voice capability. In the preferred embodiment, thetwo models each include a telephone connector, but the connectorconfigurations are slightly different between the two models. In theFIG. 3 version, an RJ-11 connector and associated wire is used toconnect the terminal 54 to a telephone wall outlet. The FIG. 4 versionincludes two RJ-11 connectors, one connected the terminal to the walloutlet and the other RJ-11 permits "in-line" connection (if the userdesires) to an exiting telephone device. In the preferred embodiment,the FIG. 3 and FIG. 4 terminals operate essentially identically and havesimilar or identical internal structures--and therefore, the followingdiscussion applies equally to both terminal embodiments (except whereindicated to the contrary).

In the preferred embodiment, terminal 54 is an asynchronous, portabledata processing device operating over unsecured dialup non-dedicatedtelephone lines. Terminal 54 includes an LCD display 102, screen controlkeys (including a PRIOR key 104 and a NEXT key 106), an array ofselection controls 108, a HELP key 110, a CANCEL key 112, and a standardalpha-numeric keypad 114. A power-ON switch (not shown) may also beprovided if desired.

In the preferred embodiment, LCD display 102 comprises a standard 4-lineby 24-character alpha-numeric liquid crystal matrix-type display device.Thus, in the preferred embodiment, four lines of text of 24 characterseach may be displayed simultaneously. Select control array 108 in thepreferred embodiment includes four momentary ON keys--each of which"points" to a different line of text currently displayed by display 102.Menu or option selections may thus be effected by displaying thedifferent options on different lines of display 102 and permitting theuser to select between the options by depressing the appropriateselection key within array 108 which points to the desired option.

An important feature of the present invention is the use of a multi-linealpha-numeric display of optimal size to allow a single standard sizeddata transmission packet (e.g., 128 bytes long) to completely define thecontent of the display. In the preferred embodiment display 102 displaysonly 4×24=96 characters--a sufficiently small (and optimal) number ofcharacters to allow all of the characters to be specified within asingle 128-byte packet carried by typical PDNs. (The preferredembodiment represents display characters in standard ASCII format sothat each character is represented by a byte of data.) This not onlyminimizes communications costs, but also eliminates the need for a"packet assembler" or associated expensive buffer memory to beincorporated within terminal 54. In the preferred embodiment, terminal54 is really "dumb" and need not provide any sophisticated processing ofreceived display data but rather may simply display the data exactly asreceived--and central computer 52 may thus completely define the displaystate of terminal 54 each time it sends any data to the terminal. Thisfeature provides additional flexibility in terms of display formats(since the central computer 52 completely determines and specifies eachand every display format displayed by terminal 54) while keeping thecosts of terminal 54 down and nevertheless providing sufficientinformation for a user-friendly interface.

In the preferred embodiment, the alphabetic letters Q and Z are found onthe "1" key of keypad 114--thus providing a full alphabetic characterselection when needed similar to an ATM). Keypad 114 may be a standard,conventional keypad or it may preferably be of a special design to bedescribed in connection with FIGS. 6A-6C (for the FIG. 3 embodiment).

In the preferred embodiment, the significance of depressing the PRIORand NEXT keys 104, 106 depends upon context (i.e., "where the user is"in the software interface at the time he depresses the key). Forexample, PRIOR key 104 may in some cases select the screen display whichwas displayed just prior to the display of the current screendisplay--and the NEXT key 106 may select display of the next screendisplay of sequence of predetermined screen displays (assuming there isa "next" screen to be displayed). In other contexts, depressing the NEXTkey 106 may serve to confirm a transaction should be performed. In stillother contexts, the PRIOR and NEXT keys 104, 106 act as scroll controlkeys (e.g., to permit the user to scroll through a list too long to bedisplayed all at once on four-line display 102). Controls 104, 106 maythus be termed user interface navigation keys since they generally allowthe user to "navigate" through the user interface comprising one or moresequences of screen displays.

Terminal 54 also includes light-prompt fields 102A-102D! not shown inFIGS. 3 and 4 but shown in detail in FIGS. 3A-3E. In the preferredembodiment, these prompt fields are independently illuminated by lightemitting diodes controlled by central computer 52, and provide thefollowing four different legends: "Enter Number"; "Select One"; "ChangeScreen"; and "or" arranged as shown in FIG. 3A. In many instances, allfour lines of display 102 will be displaying information but the userneeds to be prompted as to what inputs he should next provide (e.g.,numerical or alpha-numeric information; or selection from one ofdifferent display options). Rather than providing an additional line ofrelatively costly LCD display 102 to provide this prompt text form, thepreferred embodiment includes "light-up" prompt indicators 102a-102d! inthe form of windows backlit by light-emitting diodes 102a-102d which maybe illuminated to provide the desired prompt (or combination ofprompts).

There are four different combinations of lighted prompts commonly usedin the preferred embodiment: "Enter Number" alone (see FIG. 3B); "SelectOne" alone (see FIG. 3C); "Change Screen" alone (see FIG. 3D); and"Select One", "or" and "Change Screen" all being illuminatedsimultaneously (see FIG. 3E).

Illumination of the "Enter Number" prompts as shown in FIG. 3B wouldoccur, for example, when central computer 52 requests a numerical valuefrom the user to be entered via keypad 114. This value might be a number(e.g., the user's PIN, or a dollar amount or a date which a scheduledpayment is to be made). The numerical entry sequence is generallycompleted by entering a confirmation key (e.g., the lowermost of the"pointer" keys 108 or the NEXT key 106).

Central computer 52 would control the "Select One" prompt to beilluminated (as shown in FIG. 3C) when the user is to select one ofseveral alternatives displayed on display 102. Typically, the userresponds by making a selection--that is, by depressing the one of "soft"(i.e., programmable) keys 108 which points to the line of the display onwhich the option he desires is displayed.

The "Change Screen" prompt (see FIG. 3D) is typically illuminated whenthe NEXT key 106 is to be depressed (e.g., to confirm a previouslyentered request, and/or to move on to the next screen in a sequence ofscreens).

FIG. 3E depicts the situation when the prompts "Select One", "or" and"Change Screen" are all illuminated. These prompts would be presented tothe user when the user is to either (a) select one of the optionsdisplayed on the display 102 (by pushing one of "soft" keys 108), or (b)move on to the next (or previous) screen (by manipulating navigationkeys 104, 106).

To initiate the terminal session using terminal 54, the user need onlydepress the power-ON switch of the preferred embodiment. In response tothis power-ON switch depression, terminal 54 automatically initializesdisplay 102 and dials an appropriate internally-stored telephone numbercorresponding to PDN 56 and central computer 52. A modem (not shown inFIGS. 2 or 3) internal to terminal 54 establishes and maintains thiscommunications link with central computer 52. To communicate throughterminal 54, the user operates momentary ON keys 104-112 and/ordepresses keys of keypad 114.

If an error occurs during data entry, the terminal user may push aCANCEL key 112 to correct the error. If he pushes CANCEL key 112successively, he moves out of the function he has selected (e.g., toerase, one at a time, previously entered digits much as occurs when onedepresses the CANCEL key on a standard ATM machine) and may eventuallyreturn to a main menu. Help key 110 may be pushed at any time to obtaincontext sensitive help prompting. The PRIOR and NEXT keys 104, 106 mayact as scroll up/scroll down keys in the appropriate context as alreadydescribed.

If during a terminal session a period passes when there is no keyactivity for a certain time delay, terminal 54 times out and disconnectsthe telephone link with the PDN switch 56. In the preferred embodiment,transactions requested prior to such communications failure are notprocessed by central computer 52 unless the user has received aconfirmation over terminal 54 that the requested transaction has beenprocessed.

FIGS. 5A and 5B together are a schematic block diagram of terminal 54.Terminal 54 in the preferred embodiment includes display 102,independently controllable LED prompts 102a, 102b, 102c and 102d(corresponding to the four independent illuminated prompts describedabove), user controls 104-114, and microcontroller 116 with associatedEPROM 118 and RAM 120, an address latch 122, a bidirectionalbuffer/driver 124, an encryption functional block 126, an LED driverinverter 128, an associated latch 130, an internal modem 132, and a dataaccess arrangement/connector 134.

The FIG. 3 embodiment further includes a telephone module 136 and DTMFtone generator 138 connected to and associated with voice handset 100.The power supply 140 (e.g., a replaceable battery) is also provided topower the various components of terminal 54 (or a conventional tricklecharger circuit may be used to charge a rechargeable battery fromtelephone line voltage).

Microcontroller 116 is the heart of terminal 54. Microcontroller 116executes program control instructions stored in EPROM 118 in response toclock synchronization signals provided by the crystal clock142--preferably by applying address information on address bus linesA8-A15 and on bidirectional address/data bus P0-P7 (latch 122 may beused to latch this portion of the address) and retrieving the resultinginstructions in a conventional manner via bidirectional buffer 124 andthe multiplexed address/data bus. Microcontroller 116 similarly accessestemporary storage locations in RAM 120 and is capable of reading from orwriting to RAM in a conventional fashion (although EPROM 118 and RAM 120are shown connected in series with one another in FIG. 5B, it will beunderstood that these components may actually reside in the samepackage, so that microcontroller 116 may independently access anystorage location in either the EPROM or the RAM).

Terminal 54 if desired may further include a conventional read/writeinterface to a conventional "swipe" type magnetic card reader or aconventional "smart card". Such interface may be useful not only toinput information to terminal 54 for transmission to central computer52, but also to store information transmitted by the central computer tothe terminal. In one application, for example, central computer 52 maydownload a credit order to a magnetic card or "smart card" via terminal54--thus in effect providing electronic cash dispensing. Such downloadeddebit cards or "smart cards" may then be used to purchase goods or thelike.

In the preferred embodiment, microcontroller 116 controls display 102 bywriting parallel information to the display (which in the preferredembodiment is an off-the-shelf LCD display module including a 4×24character matrix LCD display and associated internal LCD controller) andby providing appropriate control signals to the display. A conventionalencryption arrangement which preferably uses the conventional standardDES Data Encryption Standard (described in, for example, FIPS PUB 46,Federal Information Processing Standard Publication 1977 Jan. 15 U.S.Dept. of Commerce, National Bureau of Standards) may be used to encryptand/or decrypt data in a conventional manner and provideencrypted/decrypted result to microcontroller or communications orfurther processing. The encryption arrangement may alternately compriseany other miniaturized encryption system (such as a system developed byDr. Ronald Rivest of MIT, Cambridge, Mass. and others and described inU.S. Pat. No. 4,405,829).

In the preferred embodiment, secured terminal communications is providedby on-board encryption of the user's PIN (personal identificationnumber) and financial data. The RSA (Rivest, Shamir and Alterman)encryption algorithm (somewhat similar to DES but not requiring passingof keys between the transmitter and the receiver) may be stored in EPROM118 in the form of program control instructions. The RSA encryptionalgorithm is driven by a 64-bit seed stored in RAM 120 or other RAM(which should be powered on at all times by a lithium battery) at thetime of terminal manufacture. A real-time clock 142 and associated clockpower supply 143 are also provided in the preferred embodiment (the RAMstoring the seed, the real-time clock, and the clock power supply may becontained within a single package to conserve power if desired). A copyof the seed is preferably also maintained for each terminal 54 by thecentral computer 52--and the seeds are permuted in the same ways by thealgorithms to produce random numbers in response to real-time.

During communications with the central computer 52, the terminal 54 mayuse the seed to periodically generate a pseudo-random number forencryption. This same seed is used by central computer 52 to generatethe same pseudo-random number. Because the seeds and the algorithms arethe same (assuming the real-time clocks can be periodicallyresynchronized with one another), the generated random numbers are alsoidentical to one another. The real-time clock 142 of terminal 54 may beperiodically adjusted by the central computer 52 to ensuresynchronization.

A user signing onto terminal 54 enters his PIN which is added to (or isotherwise transformed using a reversible process) the random numbergenerated by the seed by microcontroller 116. This composite number istransmitted in encrypted form to central computer 52 where the samerandom number generated independently by the central computer is used torecover the original PIN. The PIN and central computer 52 (usingstandard encryption techniques compatible with those used on the ATMnetwork 66) for transmission over the ATM network.

Preferably, the user's PIN, the unique terminal identification ("ID")stored within the terminal EPROM 118, and all financial (i.e., "amount")information passed between the terminal 54 and the central computer 52is encrypted. However, it may not be necessary or desirable to encryptother information passed between the terminal and the central computer(e.g., the screen display text information transmitted by the centralcomputer 52 to the terminal 54) since such encryption adds to the timeneeded to process the information.

A very high level of security is provided by the techniques discussedabove. No key or seed is passed between the terminal 54 and the centralcomputer 52, thus preventing an eavesdropper from obtaining the key and"spooking" the line ("spooking" refers to the process by which aneavesdropper can listen into and follow the exchange between theterminal and the central computer long enough to synchronize histerminal with the real terminal 54 and then capturing the line toreplace the real terminal with his terminal--thereby "taking over" theexchange). Preferably, the RAM storing the seed information within theterminal will lose its stored information if any attempt is made to"peel and read" the RAM and its contents. All sensitive information(PIN, terminal ID and financial information) is encrypted so that anyone"listening in" would receive in clear form only standard informationavailable to all users--with all of the information needed to performfinancial transactions (i.e., PIN, terminal ID, amounts, accountnumbers) being encrypted. Preferably, limits would be provided withrespect to the real-time adjustment provided by clock 142 so thatsomeone trying to "crack" the encryption algorithm could not derive theseed by supplying a series of known real-times. And, of course, someonestealing a terminal 54 is not provided with access to a user's bankaccount because the thief would also have to know the user's PIN.

Microcontroller 116 scans user input controls 104-114, and executesappropriate program control instructions in response to depression ofsuch controls. In the embodiment shown in FIG. 3, the same keypad 114preferably used to dial the telephone and to provide alpha-numericinputs to the terminal microcontroller 116. While it is certainlypossible to perform the various telephone functions (including DTMF tonegeneration) with an appropriately programmed microcontroller 116, in thepresently preferred exemplary embodiment of the present invention thevoice telephone functions are performed independently of microcontroller116 and associated components--with the only overlap between thetelephone functions and the terminal functions being that keypad 114controls both the telephone and the terminal.

Thus, in the FIG. 3 terminal embodiment, DTMF tone generator 138,telephone module 136, and handset 100 are used solely for telephonefunctions--with terminal telephone dialing being performed independentlyby microcontroller 116 and modem 132. An inexpensive way to provide adual function keypad 114 such that the keypad interfaces essentiallyindependently with both terminal 54 and the telephone DTMF tonegenerator 138 is shown in FIGS. 6A-6C. FIG. 6A is a top view in plan ofa single key 200 of keypad 114 including dual electrical contactportions 202,204. Preferably, the dual contact portions 202,204 areidentical to one another--with the only difference being that one of thecontact portions 202 is connected to telephone DTMF block 138 while theother contact portion 204 is connected to microcontroller 116. FIG. 6Bis a side view and cross-section of a single key structure 200 of keypad114 in the preferred embodiment. Key structure 200 includes a dome 206,a conductive rubber pad 208, a separator insulator layer 210, andcontact portions 202,204 mounted on a common printed circuit board 212.In the preferred embodiment, the DTMF block 138 is preferablyimplemented by circuitry provided on an upper surface 212a of printedcircuit board 212 facing conductive rubber pad 208. As shown in FIG. 6A,contact portion 202 preferably comprises a conventional interdigitatedpair of conductors with contact between the interdigitated conductorsbeing established by conductive rubber pad 208 whenever dome 206 isdepressed. Similarly, contact between interdigitated conductors ofcontact portion 204 is established by conductive rubber pad 208 wheneverdome 206 is depressed--but in the preferred embodiment no circuitryassociated with contact portion 204 is located on PC board upper surface212 (and instead, pass through connections 214 are used to connect thecontact portion to microcontroller 116). In the preferred embodiment,the distinct conductive rubber contact pads 208a,208b provide electricalisolation between the circuitry of terminal 54 and circuitry of DTMFmodule 138.

In the preferred embodiment, dome 206 is preferably a flat type with ashort stroke and tactile feedback. Conductive rubber pads 208a,208bpreferably have contact resistance of less than 50 ohms to provide goodelectrical contact between the interdigitated contact conductors. Theswitch shown in FIGS. 6A-6C provides a short stroke, limited tactilefeedback, relative simple design, that is, contamination proof and longlasting in operation, provides a low profile and is relativelyinexpensive to manufacture, and provides complete electrical isolationbetween microcomputer 116 and DTMF block 138.

FIG. 7A-7C are flow charts of exemplary program control steps performedby microcontroller 116 in the preferred embodiment terminal 54. Uponinitially applying power to terminal 54, microcontroller 116 clears allflags and interrupts, enables all interrupts, initializes a bufferpointer, turns off LEDs 102a,102b,102c and 102d enables a keyboardinterrupt, initializes display 102--all in a conventional manner (block250). Microcontroller 116 then waits for a key 104-114 to be depressed(decision block 252). FIG. 7B is a flow chart of a keyboard interruptroutine performed by microcontroller 116 to detect when a key 104-114has been depressed (and which key has been depressed). Whenever a key isdepressed, microcontroller 116 sets a keyboard flag (block 254) and thenreenables keyboard interrupts (block 256) before returning to the FIG.7A routine.

Upon detection by FIG. 7A decision block 252 that the FIG. 7B keyboardinterrupt routine has detected depression of a key, microcontroller 116pauses a short time period (to provide for debounce of the key; block258) and then waits for the key to be released (decision block 260).When the key has been released, all flags are cleared (block 262) andthe microprocessor 116 decodes the scanned-in information to determinewhich key was depressed (block 264). Terminal 54 then transmits the keyidentity via modem 132 over the telephone line to the FIG. 1 centralcomputer 52 (block 266) and waits for transmit to be completed (decisionblock 268). Once transmission is complete, control returns to decisionblock 252 to await depression of the next key.

At any time during the FIG. 7A routine, it is possible for terminal 54to receive data from central computer 52. FIG. 7C is a flow chart of anexemplary program control steps performed by microcontroller 116 whenmodem 132 receives a character from central computer 52. In thepreferred embodiment, the character input interrupt routine shown inFIG. 7C simply sets a character input flag (block 270) and then calls anincoming character process routine (block 272), a detailed flow chart ofexemplary program control steps of which is shown in FIGS. 8A and 8B. Inthe preferred embodiment, terminal 54 may operate in either the commandmode or display mode. In the command mode, characters received by modem132 are used to initiate various actions by the components of terminal54. In the display mode, the received characters are simply displayed(i.e., communicated to the display controller for display 102). Theterminal 54 in the preferred embodiment toggles between the command modeand the data mode in response to control signals embedded in the datastream it receives. Thus, for example, all ASCII characters may bedisplayed on display 102, but terminal 54 may interpret all characterspreceded by "escape" characters as command characters and interpret suchcommand characters rather than displaying them.

Decision block 274 tests whether the incoming character is a command ora character to be displayed (preferably based upon a bit or combinationof bits preceding or otherwise contained within the incoming character,as mentioned above). The incoming character is merely to be displayed("no" exit of decision block 274), microcontroller 116 outputs thecharacter to display 102 (block 276), enables the serial port interruptsto permit receipt of the next character (block 280) and returns to thecalling program (block 282) (the position at which characters aredisplayed is determined in the preferred embodiment based on theposition of the last character to be displayed, with an entirereplacement screen display being sent to the terminal 54 from thecentral computer 52 each time any data is transmitted to the terminal).If, on the other hand, the incoming character is a command,microcontroller 116 decodes the command and effects an appropriateresponse. For example, if the incoming command is to activate LED 102a(decision block 284), microcontroller 116 asserts the appropriate dataon the address/databus to latch an appropriate control signal and tolatch 130 so that LED 102 is illuminated (block 286). Similarly, if theincoming command indicates that LED 102a is to be turned off (decisionblock 300), microcontroller.116 causes latch 130 to latch appropriatedata such that LED 102a is dark (block 302). LED 102b-102d arecontrolled independently in a similar manner by blocks 288-298 andblocks 304-314.

If the incoming command received by modem 132 indicates that display 102is to be turned on (decision block 316), microcontroller 116 generatesan appropriate command signal to activate the display (block 318).Similarly, central computer 52 can command the terminal 54 to turn offdisplay 102 (blocks 320,322) or to clear the display (blocks 324,326).In the preferred embodiment, a string of characters to be displayed byblock 276 is followed by an end of line command character and uponreceipt of such end of line character (tested for by decision block328), any characters in excess of the line length, 24, are ignored(block 330). If the received control character is a carriage return onthe other hand (block 332), microcontroller 116 moves the displaycharacter to the beginning of the next line (block 334) so that the nextcharacter output for display by block 276 is displayed at the beginningof the following line of display 102.

Exemplary Program Steps Performed by Central Computer 52

First provided will be a brief overall description of an exemplaryremote terminal 54 user session accessing the financial servicefunctions performed by central computer 52. Subsequent to thatdiscussion will be provided a detailed description of exemplary programcontrol steps performed by central computer 52 under control of thesteps shown in flowchart form in FIG. 9 et seq.

Briefly, the terminal is powered-up by activating an ON switchpreferably on the side of the terminal. The onboard processorinitializes the terminal program which resides in an EPROM, clears thedisplay, clears the transmit buffer, commands the modem section to senda call block code and autodials the central processor's gateway number(via the PDN).

Coding in the terminal's EPROM contains SIGNON coding and messages. If alink is not established, the microprocessor displays a messagequestioning whether the redial number should be local or long accessdistance number. If the user responds indicating the number is local,the terminal modem redials the local access gateway number; otherwise itdials a long distance access number. Provision may also be made formanual dialup.

After an asynchronous communications link is established, a uniqueEPROM-based identification number is transmitted to the centralprocessor, encrypted, indicating the terminal's unique securityidentification number. The central processor terminal handler searchesan authorization file stored on database 84 for the terminal securityidentification number to determine access conditions, institutionalassociations, names of authorized users, etc.

After the terminal is identified and authorized, the central processorasks which user (in a particular household) is using the terminal. Ifonly one user is authorized to use the terminal, the central processordefaults to the next menu. The central processor then requests the userto indicate which transaction bank account (i.e., checking, NOW or otherdebit account) he wishes to use. If the user has only one transactionaccount the central processor defaults to the next menu.

After the terminal user and the transaction account are identified, theuser is requested to enter his ATM PIN (personal identification number).The PIN is transmitted (encrypted) to the central processor. The PIN isthen combined with the user's ATM card offset and account number, whichis kept on file in the central processor. This information is combinedand reformatted (using the interface module) to conform with ATMinterchange formats. The PIN (and other user identification data) isthen transmitted through the ATM interchange to the terminal user thathis terminal fully secured. Provisions can also be made to pass alongthe PIN "untouched" by the central processor.

If the bank does not authorize access to the account, indicatingincorrect PIN, a message is passed to the terminal user through theterminal display indicating access has been denied. The user is thenpermitted several additional attempts to enter the correct PIN. With thecorrect PIN, access will be permitted and the customer will receive agreeting message from his bank and his available balance.

The system thereby has two levels of security--the unique signature ofthe terminal and the unique PIN; each linked to an authorized user.

A timed advertisement or message is then typically transmitted to theterminal user. This message may be directed to the user based on ananalysis of the user's spending patterns (this information is extractedfrom user bill payments made through the terminal).

After receiving the advertisement, the user is presented (based on ananalysis of his transactions history) with the opportunity to requestfurther information on the advertisement. If he responds positively,that response indicating customer interest is communicated from thecentral processor to the advertiser (either online or in batch mode ifpreferred). The advertiser can then immediately direct a sales responseat the interested customer.

The preferred embodiment, computer system 52 may thus target third partyadvertisements to users without disclosing user confidential informationto the advertisers. An advertiser may, for example, pay to have anadvertisement directed to all users having an average bank accountbalance in excess of a certain amount or who make average monthly creditcard payments in excess of a certain amount. Central computer 52 mayaccumulate a long history of user's bill payments and bank accountbalances and use this accumulated information (in conjunction withpreferred information provided by the user when he registers for thehome billpaying service) to provide extremely sophisticated useful andvaluable demographics analysis possibly never before available due tothe lack of such detailed accumulated user information.

Needless to say, the results of such demographics analysis are extremelyvaluable to advertisers but are also extremely confidential; users wouldseriously object if any such information was ever related to thirdparties without their express permission. However, central computer 52can (in accordance with an important feature of the present invention)target specific ads to users based on such detailed demographicsanalysis without ever disclosing any confidential user information tothe advertiser. If the user requests further information in response tosuch received targeted ads, central computer 52 may then provide limiteduser information (e.g., name and telephone number) to the advertiserbased upon the user's positive request for advertisers contact. Anespecially advantageous way to provide such limited user information isto pass it to the advertiser's telemarketing department immediately inreal-time (while the user is still "on-line") since the user is thennear his telephone and is receptive to the advertiser contact. Theadvertiser may then call the user as soon as the user disconnects histerminal to free up the telephone line.

The main menu of services is then presented on the terminal display, theuser selects one of four major choices (bill paying, account transfer,account information or other services).

When bill payment is selected from the main menu of services the user'saccount balances is presented, his terminal 54 displays a unique list ofpayees (preferably specified beforehand by the user in response to aquestionaire or the like). After selecting one payee, the amount ofpayment is entered on the keypad 114 and the figures appear on display102 (but are not transmitted until a buffer is ready for transmission).The amount (preferably encrypted) is transmitted to the centralprocessor 52. The transmission is logged in on a log file, thetransaction is entered in transaction files by the bill payer module,and account information is obtained from the appropriate payee (payeenumber, payment instructions/remittance method, payee address anddeposit institution) and user account files (the user's name, address,user account number at payee, payment application) stored on massstorage device 84. A confirmation message is displayed to the terminaluser indicating that his request for bill payment has been received andlogged by the central processor.

If a bill is to be paid today (and sufficient available funds are in theuser's account), the payee identification number, customer accountnumber and PIN (unless operating in PINless mode of operation usingauthorization numbers returned by the customers bank at balancerequest), the amount and date, identification information account,destination bank descriptor information and transaction codes areobtained from database 84 files and reformatted by the interchangemodule for transmission to the customers bank through the ATMinterchange preferably in the form of a POS debit message. At the bank,the customer's account identification information and PIN (orauthorization number) permit access to his account for the purpose ofdebiting the amount of the bill to be paid. The user's bank account isdebited, and the payee identification is passed to the bank for listingon the user's monthly bank statement (paper statements or paymentverification are not sent to terminal users directly, but are combinedwith the terminal user's monthly bank checking account statement in thepreferred embodiment). A message is then sent back through theinterchange and ATM network 66 confirming the transaction (at this timeusing preferred POS debiting the bank and the network assume liability,i.e., guarantee the transaction, and the bank typically debits useraccount immediately and clears the funds to the source provider'saccount after close of business).

After payment authorization is received from the bank (through the ATMinterchange), the bill payment enters the central processor 52 from theterminal, and a series of log and transaction files are updated by thePOS and bill payer modules. The payee/vendor information file isaccessed to determine his status, electronic or paper payment, theappropriate address is obtained from the address verification file andparticular payment information is obtained from the payments descriptorfile. If the payment is scheduled for today, it is routed to theappropriate exchange (ACH) or routed to other direct electronictransmitted or remittance tape for delivery to the payee. Provisions arealso made to aggregate and time payments (from multiple terminal users)to a single payee. If the payment cannot be made by electronic means, apaper check must be cut and mailed. In cases where multiple payments canbe made to a single payee, a (single) "check and list" (of payorinformation) is forwarded. A reference number is created for eachelectronic or paper payment (this reference number is used for terminaluser and payee servicing).

If the payment is to be paid other than today (a "future payment"), asimilar logging procedure is followed, except that the payment (alongwith certain secured PIN information) is routed to a payment transactionpending file instead of being processed for immediate payment. On theappropriate day of payment, the transaction pending file is accessed andthe information necessary to affect an account debit of a user's bankaccount is retrieved and a corresponding POS debit message is generatedand sent over the ATM network at that time.

Information on the amount, payee, banking institution, user account andauthorization number are transmitted through the interchange to user'sbank. Once the debit has been completed, an acceptance of the accountdebit transmitted by the bank back to the central processor through theATM interchange.

After a payment has been made, a confirmation is received for electronicpayments, a confirmation entry is placed on the customers file and thetransactions file. Similarly, another confirmation is entered uponsending paper payments. When the user views his statement oftransactions (his online statement), the data and amount of payment isavailable for his information.

Pre-authorized recurring payments are processed in much the same manneras future payments. On the appropriate day, the user's paymentinformation is transmitted through the ATM interchange to his bank wherehis account is debited and a confirmation returned that is posted-on theuser's online statement.

When payments that have been scheduled are not processed due toinsufficient funds in the user's account, a message is posted to theuser's online statement file and a message is presented on his screenfor viewing at the beginning of the next session. In addition, theterminal user is notified by mail.

The central processor system keeps logs of all session paymentsscheduled currently or for future dates. This permits a terminal user toreview and correct the amount, date or payee for the current session orfor future dated transactions.

The transfer of funds function permits the transfer of funds within asingle bank or between cooperating banks. When the transfer fundsfunction is initiated, a menu of accounts is presented, the user selectsthe account from which the funds are to be transferred and the amount ofthe transfer (the user may also be asked to enter a new PIN if hiscurrent PIN is not tied to the applicable account). The account numberand PIN are transmitted through the ATM interchange 66 by the centralprocessor 52 to the customer's bank where a balance is obtained. A menuis then presented of the user's other accounts and he selects theaccount to which he wants funds transferred (again, if necessary, he isasked the PIN of the account if not tied to his main transactionaccount). A transfer confirmation message is displayed on the terminalscreen after entry of the necessary information indicating that thetransfer has been accepted by the central processor. The centralprocessor system keeps logs of all session transfers scheduled currentlyor for a future date. This permits a terminal user to review and correctthe amount, date or amount of transfer for the current session or forfuture dates. The central processor then transmits through theinterchange a debit to the source account and then transmits a credit tothe receiving account.

If the transfer attempt should fail because of PIN acceptance,inadequate funds or communications problems, the terminal user isnotified while online. In the case where the transfer has been scheduledfor the future or periodically, the PINs, amounts and dates must be heldin a pending transaction file. Should the transfers not take place whenscheduled, a message is posted to the use's online statement file and amessage is mailed to the user and a message is presented on his screennext time he turns on his terminal. At the completion of the transferdebit and credits, confirmation messages are transmitted by the bank tothe central processor through the ATM interchange.

The "account balance" menu selection provides information on accountbalances for the user's indicated transaction account and for other userbank accounts. In addition, there is a statement of online activitywhich summarizes the transactions that were entered during a desiredhistorical period (e.g., the last 45 days including the currentsession), an opening balance (using the oldest balance stored in thecentral processor for over the post 45 days) and the ending balance(current balance adjusted for any transactions processed during aterminal session).

In addition, information on other bank services is also available suchas, CD rates, mortgage and loan rates, special promotions, lists ofservices, etc. A terminal user may then request further information. Incertain cases, the user may also request a service (e.g., apply forloans, order new checks, and potentially perform certain non-bankingfunctions). Any service request is passed to the bank directly forservice attention similar to the way the central processor treats a userresponse to directed advertising at SIGNON. The central processor onlyaccesses the interchange when seeking to obtain an account balance,perform a debit or credit, submit adjustments stop payments andreversals; otherwise, transaction activity is limited to the centralprocessor and its databases.

The final selection permits the user to SIGNOFF the terminal, or move toanother account at the same bank or a different bank. If the terminalsession is ended, a session number and message is transmitted to theterminal (the session number is stored by the central processor and isused for customer servicing and reference). Actual bank debit and creditprocessing that was not initiated during the session is completed afterthe terminal session ends. The terminal detects an end of session-codeand the modem is commanded to break the communications. If the terminalsession ends abnormally due to a failure in the communications link,those transactions that were not entered up to the point of confirmationare not executed by the central processor. The terminal user, oncereceiving indications that the communications link is down, must pushthe ON key to reestablish a communications link and continue with hisremaining transactions. He can review his online statement oftransactions to conform what transactions have been accepted by thecentral processor.

If the user wishes to sign onto other accounts at his current bank orhis accounts in other banks, he signs on the new account (using a newPIN) and conducts business in his new account or new bank.

FIG. 9 is a flow chart of exemplary program control steps of a mainroutine performed by central computer 52 to distribute financialservices to remote terminal 54 and to communicate with such remoteterminals. Preferably, central computer 52 provided a multitaskingenvironment and a version of the main routine shown in FIG. 9 executesfor each of a plurality of remote terminals 54 in communication withcentral computer 52.

Calling the FIG. 9 main routine of block 350 starts all processes. Uponbeginning execution, the main routine first gets the system date atblock 352. The main routine then configures an I/O port assigned to it(preferably, central computer 52 includes a plurality of I/O ports forcommunication with a corresponding plurality of remote terminals 54) andinitializes this port (block 354). The main routine then initializesdata arrays and other associated data structures stored in the memory ofCPU 80, clears a "present payment" temporary storage data structure, andstores past payment information in the database(s) maintained on massstorage device 84 (block 356). The main routine then waits for a remoteterminal 54 to contact central computer 52--and upon such contact,performs the start routine which establishes a communication interchangewith the calling remote terminal, solicits the user's personalidentification encrypted and encryption initialization message, andcontrols the calling remote terminal to display an advertisement (block358). A flow chart of exemplary control steps performed by start routine358 is shown in FIG. 10.

Referring now more particularly to FIG. 10, start routine 358 receivesinitial information transmitted by terminal 54 and preferably identifiesthe terminal as corresponding to a particular user or group of users(block 360). In the preferred embodiment, when remote terminal 54contacts central computer 52, the remote terminal transmits aninternally stored identification number which identifies a particularterminal. Central computer 52 in the preferred embodiment associatesthat unique terminal identification it receives with that particularuser (or collection of users), accesses the database stored on massstorage device 84 to determine which bank or other financial institutionthat user(s) is a customer of, and then transmits a string of charactersto the remote terminal 54 which causes the terminal to display a"welcome" message in the name of the user's bank (block 362). This is animportant feature of one aspect of the present invention, since theuser's remote terminal 54 greets the user with a welcome messageappearing to come from the user's own bank rather than from the serviceprovider operating system 52--giving the bank "control" with its userrelationship and giving the user the familiarity and confidence indealing with his bank.

Central computer 52 transmits signals to remote terminal 54 using aroutine called "TIOT". Flow chart of exemplary program control stepsincluded in this TIOT routine is shown in FIGS. 11A-11D. This TIOTroutine is the communications routine in the preferred embodiment thattransmits signals to remote terminal 54 and receives signals transmittedby the remote terminal. The TIOT routine first determines whether onlydisplay is required (as is in the case of block 362 of FIG. 10) orwhether central computer 52 is to receive numeric inputs from terminal54 as well as provide a display. In the case of the FIG. 10 block 362call to the TIOT routine, only a display is required and accordingly,the TIOT routine calls a further routine called TDISPLAYM to build anoutput a block of data which when received by terminal 54 will cause theterminal to display a desired display screen (in this case, the displaywill display the message "Welcome to First National Bank" or the likealong with copyright message in the preferred embodiment) (block 402).

FIGS 11E-11F are together a flow chart of an exemplary program stepsperformed by the TDISPLAYM routine in the preferred embodiment. Thisroutine, which may be called directly from other portions of the centralcomputer software (although it is typically called by the TIOT routineshown in FIGS 11A-11D at, for example, block 402 of FIG. 11A) permitscentral computer 52 to control exactly what is displayed at any giventime by remote terminal display 102. Briefly, central computer 52 fillsa display buffer having the exact character length of the 4×24-characterdisplay 102 of terminal 54, and then communicates this buffer contentthrough the PDN network 56 to the remote terminal 54. The contents ofthis buffer constructed by central computer 52 thus completely describesthe status of display 102 (as well as LED prompt indicators 102a-102d)of remote terminal 54).

The following parameters are provided to the TIOT routine in thepreferred embodiment:

Floating point/integer/display only;

State of LED 102a;

State of LED 102b;

State of LED 102c;

State of LED 102d;

Line 1 of text, first line displayed;

Line 1 of text, successive lines displayed;

Line 2 of text, first line displayed;

Line 2 of text, successive lines displayed;

Line 3 of text, first line displayed

Line 3 of text, successive lines displayed;

Line 4 of text, first line displayed;

Line 4 of text, successive lines displayed

Inhibit/enable pointer key 1;

Inhibit/enable point key 2;

Inhibit/enable pointer key 3;

Inhibit/enable pointer key 4;

Inhibit/enable CANCEL key;

Inhibit/enable HELP key;

Inhibit/enable NEXT key; and

Inhibit/enable PRIOR key.

To display a new display format on terminal display 102, centralcomputer 52 first reinitializes formats the output for communicationwith the terminal 54 via PDN network 56 (block 1100), and then transmitsappropriate control signals to remote terminal 54 controlling the remoteterminal to blank LCD display 102 and to de-illuminate all LEDs102a-102d (blocks 1102,1104). In the preferred embodiment, centralcomputer 52 transmits two types of characters to remote terminal 54"characters to be displayed" and "control characters". In the preferredembodiment, the control characters may be preceded by an "escapesequence" to alert terminal 54 that the following character is a controlcharacter rather than a display character--or alternatively, controlcharacters may all have formats different from displayable characters topermit terminal 54 to readily distinguish between the two types ofcharacters. In the preferred embodiment, whenever remote terminalmicrocontroller 116 receives a control character, it interprets thecontrol character rather than sending it to LCD display 102.

Central computer 52 then preferably obtains a template for the desiredscreen format to next be displayed (the name of this screen format ispreferably passed to the display routine as a parameter either directlyor indirectly and may be obtained from mass storage device 84) andstores this template contents in a screen display buffer having theexact length required to fully define all characters on the4×24-character LCD display 102 of remote terminal 54. Certain templateshave variable names embedded within them--and central computer 52recognizes these variable names according to type (floating point orinteger) and in response to the presence of these variables determinesthat the corresponding information must be "filled in" to complete thebuffer contents. Preferably, the variable contents are already definedexternally from the display routine, although the variable contents maybe passed to the display routines in the form of additional parameters.Some exemplary templates are depicted in the APPENDIX, which shows anexemplary "script" of various remote terminal transactions using theremote terminal user interface provided by the system of the presentinvention.

If an embedded variable requires a floating point number to be filled into the display format template (decision block 1106), central computer52 obtains the appropriate value (depending upon the context in which adisplay routine was called) and inserts that information into theappropriate positions of the display buffer (block 1108) beforetransmitting the display buffer. Similarly, if an integer number needsto be filled in (decision block 1110), central computer 52 obtains theinteger value and inserts that into the display buffer (block 1112). Ifno variables are embedded into the corresponding template, the screenformat is termed "display only" format (decision block 1114) and centralcomputer 52 simply builds the display buffer without inserting anyadditional variable information (block 1116).

Central computer 52 then transmits the buffer contents to remoteterminal 54 beginning with the first character in the buffer and endingwith the last buffer character in the preferred embodiment. Referring toFIG. 11F, the buffer is preferably structured as four rows with each rowincluding 24 characters (and thus buffer thus constitutes a memory"image" of what is to be displayed on display 102).

Assuming the last row has not yet been transmitted (decision block 1118)and that the last character in the current row has not yet beentransmitted (decision block 1120), a character count is incremented(block 1122) and the "next" character within the display buffer istransmitted to remote terminal 54 (block 1124). This process continuesuntil the last character in the current row is reached (decision block1120), at which time central computer 52 inserts a carriage return(block 1126), increments a row counter (block 1128) and resets thecharacter counter (block 1130). When the end of the last row has beentransmitted (decision block 1118), central computer 52 preferablygenerates commands for each of the four LEDs 102a-102d and transmitsthose commands to specify the states (on or off) of these LEDs (blocks1132-1148). Preferably, such LED state information is stored with eachdisplay screen template (and/or may be provided at run time based on thecurrent state of the program) so that the transmitted information fullyspecifies the states of the LEDs.

Referring once again to FIG. 11A, once the LCD display screen block isoutputted (block 402), central computer 52 always checks thecommunications port to determine whether the user has depressed an inputkey (block 404). If an input key has been depressed, the TIOT routinedecodes the data transmitted by remote terminal 54 to central computer52 to determine which key was depressed (for example, number keydepression is tested for by decision block 406, depression of selectionkeys 108 is tested for by decision block 408, depression of the NEXT key106 is tested for by decision block 412, depression of the PRIOR key istested for by decision block 416, depression of the CANCEL key is testedfor by decision block 420, and depression of the HELP key 110 is testedfor by decision block 424). A temporary storage location called "code"is set to an appropriate value corresponding to the key depressed byblock 410, 414, 418, 422, 426 in the preferred embodiment, and the TIOTroutine then returns to the calling routine (FIG. 10 block 364 in thiscase).

In the preferred embodiment, the user input decoding is simplified byspecifying enabled and inhibited user inputs at the time block 402causes terminal 54 to build a display (such specifying function may beperformed, for example, by passing parameters to the TIOT routinespecifying which user input key strokes are to be recognized and whichkey strokes are to be ignored). For example, certain display formatscall upon the user to provide numerical data--and upon displaying suchdisplay formats central computer 52 may enable decoding of number keysby block 406 but disable decoding of all other (or certain other) keys.In the preferred embodiment, user depression of a temporarily disabledinput key simply causes block 402 to control the terminal 54 to againdisplay the same display format.

Referring once again to FIG. 10, once central computer 52 controlsremote terminal 54 to display the "welcome" message it causes theterminal to display a further message indicating that the terminal isnow secure (block 364). In the preferred embodiment, DES or RSAencryption techniques (or comparable) are used to secure thecommunications between remote terminal 54 and central computer 52. Uponsuccessful securing of the communications stream in this manner, centralcomputer 52 provides an output message to remote terminal 54 controllingthe remote terminal display 102 to indicate to the user that theterminal is now secure.

Central computer 52 then determines from the terminal identificationsent to it by the remote 54 whether the remote location at which theremote terminal is located has more than one user (decision block 366).For example, remote terminal 54 may be located in a household orbusiness location including several individuals each having their ownseparate bank account. If the database information stored on massstorage device 84 indicates that the remote terminal 54 is assigned tomore than one user (as tested for by decision block 366), centralcomputer 52 solicits the identity of the particular user using theremote terminal by, for example, outputting a list of user names andcontrolling the remote terminal to display that name list on LCD display102 (preferably also with appropriate control characters to cause the"select one" prompt to be illuminated on the remote terminal) (block368). Central computer 52 then waits for the user to select one of theoptions listed. If the user responds with depression of one of selectkeys 108, the TIOT routine 408,410 decodes the depression of theseselect keys. If the user does not depress one of these select keys 108within a certain time period (or depresses one of keys 104,106 instead),then central computer 52 concludes that the user does not appear ondisplay 102 and that further user names need to be displayed) (decisionblock 370, block 368). The user may depress the NEXT key for display ofother names.

On the other hand, if the user selects one of the listed names, centralcomputer 52 determines whether the selected user has more than one bankaccount (e.g., by accessing the database stored on mass storage device84) and if so, controls remote terminal display 102 to display a list ofaccounts (block 372), Central computer 52 then once again waits for theuser to select once of those displayed accounts and/or displays furtheraccounts corresponding to the same user if the user is unable to make aselection (decision block 374,372).

Once central computer 52 has identified a user's bank account, the TIOTroutine is called to request the user to enter his or her ATM (PIN)number (and preferably also lights up the "Enter Number" prompt at thistime). The TIOT routine then receives the user input from terminal 54.Referring once again to FIGS 11A-11D, if input is to be received (the"No" branch of decision block 400), central computer 52 determineswhether a floating number input is desired (e.g., dollars and cents suchas $301.26) (block 428). Upon this call to the TIOT routine, however, nofloating point number input is desired and therefore the routineTDISPLAYM is called to display the PIN number user prompt (block 430).Central computer 52 then waits for user input from remote terminal 54(decision block 432) and decodes the response of user input at decisionblock 432,434,440,444,448,452,458. Upon the current call of the TIOTroutine, the respective input (and in fact, the only valid input) isdepression of number keys of keypad 114 (decision block 452). As theuser depresses keys to keypad 114 indicating his PIN number, centralcomputer accumulates the digits and calculates the received number(block 454). A validity check is preferably also included in block 454at least in some context (e.g., to ensure that the desired value is ofthe proper length). In some situations, a further block 456 may controlterminal 54 to display an appropriate positive feedback messageacknowledging receipt of the entered number so that the user issatisfied that the number he has keyed in was received by centralcomputer 52.

Referring once again to FIG. 10, decision block 378 tests whether fourPIN digits have been entered and may also performs a validity check toensure that the 4-digit (or other prearranged number greater or lessthan four digits) PIN number entered corresponds to the identifiedaccount number (block 378; or alternatively, this validity check may beperformed by the bank when an ATM/POS message is sent to the user's bankaffecting this account). If the inputted PIN number does not correspond,one or more retries may be permitted before central computer 52disconnects telephone connection with remote terminal 54.

On the other hand, if the inputted number is valid, central computer 52transmits advertising or messaging text to remote terminal 54--thisadvertising text preferably being targeted to a specific user or usergroup (block 380). Specifically, in the preferred embodiment, the userdatabase stored on mass storage device 84 includes demographic and otherinformation about each user, and central computer 52 may beappropriately programmed to transmit different advertising text todifferent users. Thus, for example, all users having a bank account witha particular bank and who owned homes (detected by mortgage payments ora lack of rental payments in the database) may be sent advertising textpertaining to home equity loans, while users renting apartments(detected from the rental payments in the database) may be sentadvertising pertaining to personal loans or automobile loans instead. Ofcourse, the content of the advertising is arbitrary and might be used toadvertise any good or service. Moreover, the advertisement can becommunicated and targeted to particular users without release ofconfidential user information to the advertiser (until the userauthorizes such release as described below).

Central computer 52 then preferably sends an additional display screento remote terminal 54 asking the user whether he wants additionalinformation (block 382) via an additional call to the TIOT routine.Preferably a 3-second time response is initiated at this point so thatif the user does not respond within three seconds the central computergoes on and executes return 386 to the FIG. 9 main routine. If the userresponds with a "yes" response (i.e., by depressing the appropriate oneof select keys 108 "pointing to" a line of information displayed ondisplay 102 indicating "yes" response), central computer 52 stores theuser address and other appropriate information into a file which is sent(e.g., electronically via a dialup line) to the user's bank (or otheradvertiser) so that the advertiser can directly contact the user bymail, telephone (perhaps using autodial to get immediate access to theuser after he terminates his terminal session) or otherwise to provideadditional information about the advertised service or merchandise(block 384). On executing return block 386, the main menu routine iscalled to permit the user to select financial transactions to beperformed (see FIG. 9, block 388). A flow chart of exemplary programcontrol steps included in this main menu routine is shown in FIG. 12.

Main menu routine 388 causes remote terminal 54 to display a "main menu"(preferably using via a call to the TIOT routine) (block 390, FIG. 12).This main menu display screen lists four options in the preferredembodiment: pay bills; transfer funds; get account information; and exitaccount session (see FIGS. 3 and 4, which each depict preferredembodiment terminal displaying the main menu). The main menu providessome options of the type users are used to seeing at ATMs (e.g.,transfer funds, get account information) as well as additional optionsnot available on an ATM (e.g., pay bills). The user is then expected topress one of select keys 108 to select one of the four displayed options(the "Select One" prompt is preferably illuminated to prompt the user todepress one of pointer keys 108 pointing to the displayed option hewould like to select). User selections are received using the TIOTroutine and decoded with main menu routine 388 (decision blocks 391,393, 395, 397). In the preferred embodiment, the number of main menuoptions available for user selection is limited to four--that is, by thenumber of different lines of text that may be simultaneously displayedby display 102. Each main menu option then has additional "suboptions"which are displayed sequentially after the user selects the desired mainmenu option (as will be explained shortly).

If the user selects the "pay bill" option (decision block 391), centralcomputer 52 executes the "bill process routine" (block 392), a flowchart of which is shown in FIG. 13.

Referring now to FIG. 13, the "bill process" routine 392 performs thefunction of processing, reviewing and correcting billinginformation--and also permitting the user to electronically requestfunds to be debited from his bank account and used to pay bills toparticular desired creditors on specified dates. Upon selecting the "paybill" main menu option, bill process routine 392 may provide accountbalance information to the user by forming a standard account balanceATM or POS type message (or possibly using a "null" POS debit message)containing the user's account number and PIN and transmitting thisrequest over the ATM network to the user's bank; receiving the user'saccount balance from the user's bank over the ATM network in the form ofa return ATM message; reformatting this received account balanceinformation; and transmitting the account balance to the remote terminal54 using the TIOT routine discussed earlier (block 502). Centralcomputer 52 may also temporarily store this account balance in thepreferred embodiment for purposes of keeping a running total, as will beexplained.

In the preferred embodiment, central computer 52 appears on the ATMnetwork as simply another ATM machine or POS node--and uses the samestandard messaging formats used by ATM machines and POS terminals toobtain and receive information from the user's bank. Included in theATM/POS communications format/protocol standard used by the ATMinterchange network described previously is a command format to requestaccount balance information. Central computer 52 generates such anaccount balance request using the account number (and preferably alsothe user PIN number) provided by the user earlier, then receives fromthe ATM network a response containing the account balance pertaining tothe user's bank account. Since this account inquiry request generated bycentral computer 52 "looks like" a request generated by any ordinary ATMor POS device, the user's bank's data processing system and the ATMnetwork are capable of handling this request in a routine, ordinary way(and no software changes at the bank's end are required to respond tosuch messages).

In the preferred embodiment, the account balance information obtainedfrom the ATM network is provided to the user in the form of a display onremote terminal display 102 and is also stored in the memory of centralcomputer 52 to enable the central computer to automatically inhibit theuser from attempting to disburse more funds than he has available. Thebill process routine 392 then controls remote terminal 54 to display a"submenu" providing the user with three options: pay new bill; reviewand correct payments; and exit bill paying. Bill process routine 392then waits for the user to select one of the three options by depressingone of terminal select keys 108.

The user selections are decoded by decision blocks 504,508,512 andcorresponding routines 506,510,514 are called in response. For example,if the user depresses the upper selection key 108 in the preferredembodiment (pointing to the option "pay new bill" or "pay anotherbill"), bill process routine 392 calls a further routine 506 called"bill pay" a detailed flow chart of exemplary program steps of which isset forth in FIGS. 14A-14C.

Referring now more particularly to FIGS. 14A-14C, the "bill pay" routine506 processes bill payments by controlling remote terminal 54 to displaya list of payees and also controlling the remote terminal to light upthe prompts, the "Select One" prompt "Or" prompt, and the "ChangeScreen" (i.e., by sending appropriate control characters to remoteterminal 54 to cause those various prompts to become illuminatedsimultaneously). In the preferred embodiment, the user is asked throughdirect mailings (or in certain cases by telephone) to provide, ahead oftime, the names, addresses, account numbers, and other informationspecifying payees he wishes to pay bills to electronically (the user isalso asked for other relevant account information for other servicessuch as funds transfers). Generally, most people pay a vast majority oftheir monthly bills to the same payees every month. For example,recurring monthly bills are typically received from utility companies(gas, telephone, electric), the mortgage company or landlord, lenders,credit card companies (AMEX, Mastercard, Visa), department stores, stateand local government authorities (e.g., city or county taxingauthorities), etc. Therefore, the user is typically able to definebeforehand the dozen or two dozen payees to which he sends recurringpayments on a monthly or other periodic basis. Such user-specific payeeinformation is stored by central computer 52 on mass storage device 84and is accessed by FIG. 14A block 516 to display a list of payees. Ifdesired, the initial listing displayed by block 516 may constitute alisting of categories of payees rather than individual payees (althoughin the preferred embodiment an actual listing of payees is displayedinitially).

As mentioned previously, the preferred embodiment remote terminaldisplay 102 is only capable of displaying a limited number of lines oftext simultaneously (e.g., four). In the preferred embodiment, adifferent payee is displayed on each of these lines to permit the userto select a desired payee by depressing one of select keys 108 pointingto the displayed payee name. Generally, then, a particular user willhave a longer list of payees than may be displayed on display 102simultaneously. If the user does not select one of the displayed payees(e.g., by either not depressing one of select keys 108 or by pressingthe PRIOR or NEXT key 104,106) (as tested for by decision block 518),central computer 52 attempts to display the "next" or "previous" 4-payeesublist of the user's payee list (decision block 520,522,516). Thus,blocks 516-522 may be visualized as defining a 4-line long "window"scrolling up and down through a user payee list that may be of anydesired length. If the user reaches the end of his payee list withoutmaking a payee selection, block 524 is programmed to return to thebeginning of the bill process routine 392 shown in FIG. 13.

When decision block 518 determines that the user has selected one of thedisplayed payees, central computer 52 determines whether the user hasalready paid a bill to this same payee in the current remote terminalsession (block 526). In the preferred embodiment, the result of a givenremote terminal bill paying session is an output file containing all ofthe requested financial and other transactions generated during theterminal session. Only after the session is complete in the preferredembodiment is the output file processed by central computer 52 to effectthe various user requests. In the preferred embodiment, decision block526 scans through the output file to determine whether the user hasalready requested a transaction with respect to the currently selectedpayee, and if so, controls remote terminal 54 to display a prompt askingthe user whether he wishes to make another payment to the same payee(block 528). In this way, the user must consciously decide to makemultiple payments to the same payee and central computer 52 thusprevents the user from inadvertently making a double payment he did notwish to make.

The "bill pay routine 506" then requests further information from theuser regarding the amount to be paid to the selected payee by callingthe TIOT routine (block 530). Referring now once again to FIG. 11B,central computer 52 may control display terminal 54 to display a promptor other information (e.g., a prescheduled amount or informationregarding the last payment made to this particular payee), and thenawaits user input (blocks 464,466). The user is permitted to enter theamount to be paid (the user inputs this value without the decimal pointby striking keys or keypad 114 in the style of ATM data entry). When theuser has entered an amount he depresses selection key number 4 (block472) and the number is compared to a maximum permissible limit (block474). If the amount entered is within limits (central computer 52expects a floating point value, generally at least three numericaldigits) the routine returns; otherwise, the display is output (block476) with a blank line and an error code is set (block 478) and then theroutine returns. During number entry, the user may depress the CANCELkey at any time to "delete" or "undo" the last number keyed in, andcentral computer 52 will in response send a new screen showing thenumerical value the user has keyed in minus the deleted digit.

Referring once again to FIG. 14A, the central computer 52 then causesremote terminal 54 to display to the user a prompt asking whether theuser wishes the bill to be paid today or in the future (decision block532). If the user responds affirmatively (e.g., by depressing anappropriate one of select keys 108 pointing to a "Today" datalinedisplayed on display 102), this information along with the amount ofinformation required by block 530 is logged to the temporary output fileand a confirmation message is sent for display by terminal display 102(preferably indicating the date, the payee and the amount along with themessage "confirmed for today") (block 534). If, on the other hand, theuser responds "Future" to the question, central computer 52 asks theuser whether the bill is to be paid in the future (decision block 536).Through successive such user prompts (some prompts possibly providingmultiple options to reduce the total number of prompts that must bedisplayed by terminal display 102), decision blocks 538, 542,548determine the time period the user wishes the bill to be paid. Forexample, in the preferred embodiment, if the user wants the bill to bepaid in the future, central computer 52 may cause remote terminal 54 todisplay a listing of the succeeding two months (e.g., if the currentmonth is September, terminal display 102 may display the month ofOctober and November along with additional options such as "othermonths" and "periodically"). The user may select one of the displayedoptions by depressing the appropriate one of select keys 108 "pointingto" the displayed option he desires.

If the user selects one of the displayed months, central computer 52logs the payment in its output file which it will eventually add to ascheduled transaction log so that the payment will automatically beprocessed on the appropriate day (blocks 538-546). If the user wants toschedule bill payment for some other month, on the other hand, (decisionblock 548), central computer 52 may prompt the user by displaying monthnames three at a time until the user selects one of the displayed months(blocks 550-552). If the user selects a month that is more than a yearaway, the instruction is ignored and terminal display 102 displays amessage that system 50 can only schedule initial payments within thecurrent year (decision block 554,556). The preferred embodiment does,however, permit users to schedule non-initial (i.e., periodic) paymentsbeyond one year into the future. Otherwise, central computer 52 causesterminal display 102 to display a confirmation message indicating theamount, payee and month, and then obtains the day of the month from theuser at block 560. Control then returns to bill process routine 392 sothe user may either pay another bill, review existing bills constructedto be paid, or exit the bill paying function (block 562).

Referring now to FIG. 14C, if the user wants the bill to be paid butdoes not want the bill to be paid today or at a date in the future, thencentral computer 52 permits the user to schedule periodic bill payment(decision block 564). To schedule periodic bill payment, centralcomputer 52 controls terminal display 102 to display a prompt "startpaying bill on" and then expects the user to fill in the month day andyear that periodic bill paying is to begin (block 566).

A routine called CHKDATE is then called at block 568 to check for avalid user inputted date (e.g., a date that is equal to or later thantoday). FIG. 15 is a flow chart of exemplary program control stepsincluded within the CHKDATE routine 568.

Referring now more particularly to FIG. 15, central computer 52determines whether the inputted year is later than the current year andalso checks whether the inputted month is later than the current monthif the year is the current year (decision blocks 570,572). In thepreferred embodiment, scheduled bill payments can begin in any month ofany year but cannot begin in the past. If the user requests an invaliddata to begin periodic payments, central computer 52 controls terminaldisplay 102 to display an error message (block 574) and sets an errorflag (block 576). Similarly, block 574 displays an error message if asubsequent validity check on the year and month inputted indicates thatthe year and month are not "legal" (as tested for by decision block578). A flag is set upon entry of such an "illegal" date (i.e., a datein the past) and the user is given the opportunity to enter a correctdate upon return to calling routine.

Thus, the results returned by the CHKDATE is a date flag (whichindicates whether or not a valid date was inputted or not) and a date tobegin periodic payments.

Once a valid start date for scheduling periodic payments has beenreceived by central computer 52 (decision block 579 of FIG. 14C checksthe flag returned by the CHKDATE routine to ensure the date is legal),the central computer controls terminal 54 to provide a prompt indicatingan ending date in terms of day and year (block 500,502). In addition,central computer 52 requests the user for additional informationregarding the recurrence of the scheduled payments (e.g., weekly,semi-monthly, monthly or other; block 584). Once the requiredinformation has been obtained by central computer 52, the centralcomputer calculates each date on which a scheduled payment is to be made(block 584) calling the DATES routine a detailed flow chart of which isshown in FIGS. 16A-16B.

Referring now more particularly to FIGS. 16A and 16B, dates routine 574calculates periodic dates based upon user-inputted data--and thus allowsthe user to schedule recurring payments (e.g., loan or mortgagepayments, installment payments, etc.).

As mentioned previously, FIG. 14C blocks 556,580 and 582 obtain from theuser the beginning to start the periodic payments and the ending datefor ending payments. Routine 584 shown in FIGS. 16A-16B calculates eachof the scheduled periodic payments from this inputted information alongwith a further input solicited from the user specifying the frequency ofthe periodic payment (e.g., monthly, weekly, semi-monthly or otherperiodicity). Decision 586 first confirms that the end date is laterthen the beginning date (decision block 586). If this validity checkfails, an error message is displayed on terminal display 102 (block588), an error flag is set (590) and a return to the calling program isperformed (block 592). Assuming the end date is valid, then routine 584determines whether the beginning year and the ending year are equal toone another (decision block 594) and if so, whether the beginning monthis before the ending month (decision block 596). If the beginning andending year are equal and the beginning month is not prior to the endingmonth, then the user has attempted to schedule payments beginning laterthan they end and an error message is output and an error flag set(block 598,600). Assuming the beginning day-month-year and the endingday-month-year dates are correct, routine 584 then calculates eachpayment date within that time span based on whether the payments arescheduled weekly, semi-monthly, quarterly, semi-annually or annually(blocks 602 and on).

The manner in which the schedule of payments is calculated is similarregardless of the frequency of occurrence of the payments. For example,if the period is weekly (as tested for by decision block 602), a flag isset to indicate the periodicity (block 604) and then each of theindividual payments are calculated (blocks 606-610). Routine 504determines whether the current month/week is the last month/weekscheduled for payment (decision block 606), and if not it calculates thenext payment date by incrementing a date based on the beginning paymentdate by the number of days specified in the period (block 608). Blocks606, 608 are performed repetitively until the end date is approached, atwhich point the last payment date is calculated (blocks 610). Thecounting is performed using calendar information stored on mass-storagedevice 84 so that payments are not scheduled on invalid days (e.g., the31st of February or on bank holidays). Blocks 612-614, 606-610 similarlycalculate biweekly payments; blocks 616-624 calculate monthly payments;and blocks 626-642 calculate quarterly, semiannual and annual paymentsas will be understood.

Referring once again to FIG. 14C, after the dates have been calculated aconfirmation message is generated confirming the payee begin and enddates that have been encrypted (block 644) and the bill process routineshown FIG. 13 is called (block 646) to provide the user with the optionof paying an additional bill, reviewing the existing bills, or exit thebill paying function.

Referring once again to FIG. 13, the user may select to review andcorrect bills by selecting an option from the "bill process" menudescribed earlier. This user selection (tested for by decision block508) causes central computer 52 to call the REVCOR routine 510 a flowchart of which is shown in FIGS. 17A-17C.

Referring now to FIGS. 17A-17C, the REVCOR routine allows the user toreview and correct bill paying instructions inputted via the"billpaying" routine 506 described above. Upon selecting this review andcorrect option, central computer 52 sends a display to remote terminal54 providing the user with options to select between (a) reviewing orcorrecting payment schedules in the current terminal session, and (b)reviewing or correcting payments scheduled in a previous terminalsession. As discussed above, payments scheduled in a current terminalsession are stored in an output file that is not acted upon by centralcomputer 52 until after the current terminal billpaying session hasterminated. Once the current terminal session has terminated, allrequested payments are processed--and payments requested to occur areimmediately acted upon. Thus, the user cannot view and correct andcorrect payments that have already been transacted in response to hisprevious requests. However, the user is able to review and/or correctpayments he has scheduled in the current session, and may also reviewand/or correct payments he scheduled during a previous terminal sessionto occur after the date of the current terminal session.

If the user responds that he wishes to review payments scheduled duringthe current session (as tested for by decision block 670), centralcomputer 52 first determines whether the user has in fact scheduled anypayments during the current session (decision block 672). If no paymentshave been scheduled for the current session, a message to that effect issent to remote terminal 54 (block 674) and returned to the bill processroutine 392 as performed (block 676). If bills have been paid during thecurrent session, on the other hand, a "this session" flag is set (block678). On the other hand, if the user requests review of paymentsscheduled during a previous session (as tested for by decision block680), then a "previous session" flag is set and is otherwise not set(blocks 680, 682).

Central computer 52 then accesses appropriate data (depending uponwhether previous session or current session flags are set by block682,678, respectively) sorts the scheduled payments by date, anddisplays a list of scheduled payments (in the preferred embodiment thislist specifies month and day, abbreviated payee name, and paymentamount) (block 684). Preferably, the first such screen displayed has aheader stating "payments this session that you may correct" or "priorscheduled payments that you may correct" on the top two lines ofterminal display 102--but further screens list a different scheduledpayment on each line of the display (so that few such payments may belisted on each screen in the preferred embodiment). The user may selectany one of the displayed scheduled payments by depressing thecorresponding selection key 108 (tested for by decision block 686). Ifthe end of the list of scheduled payments has been reached and noselections remain (tested for by decision block 688), program controlreturns to the bill process routine 392 shown in FIG. 13 (block 690).Otherwise, if no selections have been made but the end of the paymentlist has not yet been reached (the "no" exit of decision block 688), alist counter is incremented to display the next few entries in the list(block 692), and those entries are then displayed by block 684 for userselection.

Referring now to FIG. 17B, once the user selects one of the scheduledpayments from the displayed list, central computer 52 transmits adisplay screen to the terminal 54 presenting the user with the followingoptions in the preferred embodiment: "correct amount", "correct paymentdate", "correct both amount and payment date", and "cancel payment". Theuser may select one of these options by depressing the corresponding oneof select keys 108. If the user requests correction of the amount (astested for by decision block 694), the preferred embodiment centralcomputer 52 transmits a display format for display on terminal display102 specifying the available funds remaining in the user's bank account(not including the previously scheduled payment amount), the name of thepayee, and a user request to enter desired payment amount (block 696).The user then is expected to use keypad key 114 to enter the desiredcorrected amount of the payment. Once the user has inputted suchinformation, central computer 52 calls a routine called BALCHECK whichchecks the user's bank account balance before the scheduled payment toensure that the user does not inadvertently overdraw his account (block698).

Referring to FIG. 18, a flow chart of exemplary program control stepsperformed as part of the BALCHECK routine 698, central computer 52compares the requested payment amount with the balance remaining in theuser's bank account assuming all immediately scheduled payments areprocessed (decision block 700). As described previously, in thepreferred embodiment central computer 52 obtains the user's current bankaccount-balance via a "account inquiry" request transmitted over the ATMnetwork 66. Central computer 52 progressively debits the amount of thisbalance as the user schedules payments to be processed immediately--sothat the central computer maintains a running balance of the user'saccount without yet actually debiting the user's account electronically.If the desired payment exceeds the user's remaining balance, an errorflag is set (block 702). Otherwise, an error message will be sent (block704) and the error flag is set (block 706) before a return to FIG. 17block 708 is performed.

Referring once again to FIG. 17B, decision block 708 tests the value ofthe error flag returned by balance check routine 698. If the user'saccount will become overdrawn by the current payment, then the user isrequested to reenter the amount (block 696). Otherwise, the runningaccount balance maintained by central computer 52 is updated and thecorrected payment information is placed into the output file (block 710)before a confirmation message is sent to be displayed by terminal 54(block 712).

If the user selects a change in payment date (as tested for by decisionblock 714), central computer 52 controls terminal 54 to display theearlier-described screen display specifying when bill payment is to bescheduled and performs steps similar or identical to the steps describedin connection with blocks 532-560 of FIGS. 14A-14B. The updatedscheduled payment date information replaces the earlier schedule paymentinformation stored in the output file and a confirmation messageembodying the updated information is displayed on terminal display 102.

If the user wishes to change both the amount and the date (block 716),then the combination of the steps performed in response to positiveresults of decision blocks 694,714 are performed. If the user wishes tochange both amount and date, a flag is set and he is passed back throughthe block 694 and 714 coding. He then passes through both sets of codingmaking the appropriate changes.

Referring now to FIG. 17C, if the user decides to cancel a scheduledpayment (tested for by decision block 718), central computer 52 updatesthe running user account balance it maintains (e.g., by merely addingthe payment amount being cancelled to the user balance amount) and alsoupdates the output file to remove the scheduled payment (block 720).Central computer then controls terminal display 102 to display aconfirmed cancellation message (block 722) so the user is assured thescheduled payment has been cancelled.

Referring once again to FIG. 13, if the user selects to exit billpaying(as tested for by decision block 512), a bill exit routine 514 isperformed. This "bill exit" routine 514 (shown in more detail in FIG.19) is responsible for processing the payment entries in the output filescheduled for immediate payment. Referring to FIG. 19, such processinginvolves calculating the total amount represented by the bills scheduledfor immediate payment (block 750) and then providing a display orsummary information to the user (blocks 752,754). Assuming the userrequests no other services (blocks 756-760), a debit request isgenerated in real-time by central computer 52 and transmitted over theATM network 66. This request may be in the form of a POS debit messagespecifying the user's PIN and bank account and the amount of the bill tobe paid and requests the calculated total amount to be debited from theuser's bank account and credited to a holding account maintained by theservice provider at the service provider's or the user's bank (perhapseven debiting the funds directly to the ultimate bill payee in anaccount at the user's bank). Central computer 52 then writes the outputfile to appropriate databases maintained on mass storage device 84 forpayment processing. Thus, in the preferred embodiment, a singlereal-time user account debit request is generated, and that debitrequest representing the amount of the immediately scheduled billpayment. Central computer 52 then activates additional processes whichmake payments in the user-selected amount to the user-selected payeesusing electronic funds transfers (e.g., ACH), generation of paper checksusing check printer 86, and the like as appropriate. The communicationslink with terminal 54 may be disconnected at this time (block 768),

Once the billpaying function has terminated (and if the user requestsadditional services; block 756), control returns to the main menuroutine 388 shown in FIG. 12. At this point, central computer 52 onceagain transmits the "main menu" display format for display on terminaldisplay 102. On this main menu, the user may decide to pay additionalbills, if desired (tested for by decision block 391), or he may decideto take advantage of other services such as transferring funds betweenaccounts or obtaining information about specific accounts. If the userrequests funds transfer (as tested for by decision block 393), theroutine called TRANSFD is called (block 394). A flow chart of thisroutine 394 is set forth in FIGS. 20A-20D.

Referring now to FIGS. 20A-20D, central computer 52 first controlsterminal 54 to display a listing of the user's bank accounts (block800), which the user had previously submitted to the service provider(along with payments information as described above). The user may thenselect one of the displayed accounts by depressing the correspondingselection keys 108 (as tested for by decision block 802). If the userdoes not select one of the displayed accounts, central computer 52increments an account table pointer (block 804) and then tests whetherthe end of the user's account list has been reached (decision block806). If the end of the list has been reached, central computer 52returns to the main menu routine 388 (block 808).

If the user selects one of the displayed accounts, central computer 52controls terminal display 102 to display a screen format identifying theaccount and the account balance (a request over the ATM network 66 toobtain this account balance may be generated at this point if centralcomputer 52 has not already obtained this account balance informationpreviously) and prompting the user to enter the amount to be transferred(block 806). The user is then expected to enter a dollar amount usingkeypad 114, which central computer 52 receives (block 808) and compareswith the account balance (decision block 810). If the transfer amountexceeds the account balance ("yes" exit of decision block 810), an errormessage is generated for display by terminal display 102 (block 812) andblocks 808,810 are performed again. If, on the other hand, the transferamount is less than the account balance, a list of user accounts(preferably minus the account from which money is to be transferred) isdisplayed (block 818) and the user selects a further account to whichthe funds are to be transferred (blocks 816,822) in a similar manner tothe first account selection (blocks 802-808).

Central computer 52 then controls terminal display 102 to display aconfirmation message (block 824) specifying the account selected forfunds to be transferred into and requesting user confirmation. If theuser fails to confirm this information (the "no" exit of decision block826), central computer 52 preferably controls terminal 54 to display anerror menu presenting the user with the options "Retry the transfer","access other services", or "end this session", (block 828). If the userrequests a retry (as tested for by decision block 830), a return to thetop of the TRANSFD routine 394 is performed. If the user wants to accessother services (tested for by decision block 832), a return to the mainmenu routine 388 shown in FIG. 12 is performed (block 834). If the userselects the "end session" option (decision block 836), then a routinecalled "session exit" to be described in greater detail shortly isperformed.

Referring now to FIG. 20C, if the user confirms the account transferrequest ("yes" exit of decision block 826 of FIG. 20B), central computer52 prompts the user whether transfer is to be performed immediately andreceives the user's response. If the user requests an immediate transfer(the "yes" exit of decision block 824), the confirmation message istransmitted to remote terminal 54 (block 826). The user may be asked toinput the PIN of the account to transfer money into at this time.Central computer 52 then generates a pair of messages to be applied tothe ATM network 66: a POS debit to the account to transfer money fromand POS credit to the account to transfer money into. These two accountsneed not be in the same bank, since central computer 52 may reach anybank on the ATM network with the messages. In effect, the real-timetransaction is to: (a) debit the user's first bank account and creditthe services provider's account; and (b) credit the user's second bankaccount and debit the service provider's account (the net result being afunds transfer). In the case where this methodology is not appropriateor feasible, debits are processed as normal ATM/POS transactions andcredits are made by ACH, magnetic tape or other electronic means to theuser's bank.

If, on the other hand, the user responds that the fund transfer is notto be performed immediately (the "no" exit of decision block 824), thepreferred embodiment central computer 52 transmits a further display toterminal 54 prompting the user as to which month the transfer is to beperformed. For example, if the current month is November, the preferredembodiment central computer 52 will transmit a screen for display byterminal display 102 specifying November, December, January and (othermonth) for selection by the user. If the user selects the current month(tested for by decision block 900), a month/date field is setaccordingly (block 902). Similarly, if the user selects anotherdisplayed month (tested for by decision block 904), the same month fieldis set in accordance with the month specified by the user (block 906).Either way, central computer 52 then prompts the user to specify a day(block 908). In response to receipt of such a date, central computer 52transmits a confirmation message for display by terminal display 102(block 910) and then schedules the transfer to account in the future atthe date specified by logging to the output file (and eventuallyupdating the database files stored on mass storage 84).

If the user wishes the account transfer to occur in some other month(decision block 912), central computer 52 displays a list of monthsthree-at-a-time (block 914) and permits the user to scroll through thislist for month selection (blocks 916-920). In the preferred embodiment,central computer 52 does not permit the user to schedule a payment morethan one year in advance (decision block 918) (although this may bechanged depending upon the application). Once the user selects a validmonth, central computer 52 obtains a desired payment date from the user(block 922) and transmits a corresponding confirmation message (block924).

Referring now to FIG. 20D, in the preferred embodiment it is possible toschedule periodic account transfers (this user selection is tested forby decision block 926). As described previously, central computer 52obtains a beginning valid date (blocks 928-932) and an ending valid date(blocks 934-936), calculates all of the periodic payment dates bycalling the DATES routine shown in FIGS. 16A and 16B (block 938), andthen transmits a confirmation message (block 940). The resultingcalculated transfers are then logged to the output file for processingon the dates specified. This permits users, for example, to timetransfers between accounts in order to maximize interest (such as movingfunds into a non-interest bearing checking account at the latestpossible date in order to meet a periodic mortgage payment).

Blocks 942-950 permit the user to select different ways to exit theTRANSFD routine 394 (e.g., by starting the routine from the beginning,block 942; by returning to the main menu routine, blocks 944,946; and byending the terminal session, blocks 948-950).

Referring once again to FIG. 12, another option provided for userselection by main menu routine 388 is the "account information" option,decision block 395). In response to this selection, central computer 52calls a routine called ACCINF (block 396). A detailed flow chart of thisroutine is shown in FIGS. 21A-21C.

Referring now more particularly to FIG. 21A-21C, central computer 52sends to terminal 54 a display format announcing that "accountinformation service" is being provided and then present the user withvarious options to select (e.g., "account balance", "statement ofactivity", and "other bank information"). If the user selects theaccount balance option (as tested for by decision block 950), thepreferred embodiment central computer 52 transmits the balance of the"primary" account (block 952). This "primary" account designated by theuser in advance (i.e., when he first subscribes to the remote financialdistribution service or when he logs onto his remote terminal at thebeginning of the current session) and is probably the account thebalance of which the user is interested in. Following this accountbalance display, central computer 52 transmits an additional displayscreen to terminal 54 presenting the user with the following additionaloptions: "balance for other account", "access other services" and "endthis online banking session". If the user then selects the "otheraccount balance" option (tested for by decision block 954), centralcomputer 52 controls terminal display 102 to display a listing of theuser's other accounts (block 956) and permits the user to scroll throughthe list to select another account (blocks 958-962). If the end of thelist is reached (tested for by decision block 962), control is returnedto the "account balance" prompt (block 950). If the user selects anotheraccount, on the other hand, central computer 52 transmits a designationof this account along with its balance (and, if necessary, generates arequest on ATM's network 66 obtaining this account balance) (block 964).A request for "other services" in the preferred embodiment is handled byreturning the user to the main menu routine 388 (blocks 966-968), whilean "end session" request is handled by calling the SESSEXIT routine tobe discussed shortly (blocks 970,972).

Referring now to FIG. 21B, if the user selects "statement of activities"(decision block 974), then central computer 52 begins controllingterminal 54 in the preferred embodiment to display a list of all paymenttransactions beginning with the oldest payment within a "30-45 daylookback" from the current date (block 976). The user may scroll throughthis listing by depressing the PRIOR and NEXT navigational keys 104 and106 as previously described. Following the history of payments processedduring the last month (which, incidentally are obtained from thedatabase stored on mass storage device 84), central computer 52 accessesthe output file and displays a list of the current session activities(block 978) beginning with the first payment. Such list includes thedate, the payee and the amount. Finally, central computer 52 calculatesa summary including the following information: the closing balance onthe date of the oldest payment (central computer 52 stores the closingbalance at the end every session on mass storage device 84 in thepreferred embodiment), the total online banking activity, the totalrepresenting all other activity, and the current balance after all thetransfers and payments requested in the current terminal session havebeen processed (block 980). The user may then access other activitiesvia the main menu (blocks 982,984) or may end the current terminalsession (blocks 986,988).

If the user selects the option for "other bank services" in thepreferred embodiment (block 990), central computer 52 controls terminaldisplay 102 to display an additional submenu presenting the user withthe options "other promotions", "service information" and "rateofferings" (as will be understood, various additional or differentservices may be presented to the user at this point). In response touser selection of one of these options (decision blocks 992,994,996decode the user selection), central computer 52 obtains the appropriateresponsive information from mass storage device 84 and controls terminaldisplay 102 to display such information (block 998). Similar to earlierdescribed advertising routines, the central computer 52 then prompts theuser whether he wishes to obtain additional information on the selectedservice (block 1000). If the user responds in the affirmative, centralcomputer 52 controls terminal display 102 to a message that the bank orother appropriate entity contact the user directly (block 1002) and thencreates a request on database 84 for transmission of the user's name,address, telephone number and the subject matter the user is interestedin for immediate or later transmission to the bank or other appropriateentity via dialup line 70 or interface/multiplexer 82 or the like (block1004). The user may then select to return to the main menu (blocks1006,1008) or may decide to end the current terminal session (blocks1020,1012).

One of the "other services" offerings may, for example, be completing aloan application. Central computer 52 already stores sufficient personaland financial information about the user to complete most of the loanapplication form automatically and may need to ask the user only a fewquestions (e.g., loan amount, type of loan, etc.) to complete theapplication (to which the user may respond with numeric or alphabeticalinformation as appropriate by depressing keys or keypad 108). Suchcompleted loan applications may then be forwarded electronically or inhard copy form to lending institutions for further processing.

Referring once again to the main menu routine 388 shown in FIG. 12, theuser at any point may decide to terminate the current terminal session(decision block 397). In response to this user selection, centralcomputer 52 executes a routine called SESSEXIT (block 398), a detailedflowchart of which is shown in FIG. 22. Referring now to FIG. 22,central computer 52 preferably first controls terminal display 102 todisplay a confirmation screen presenting the user with the options toeither end this online banking session or to "move to account in anotherbank" (block 1025). If the user decides to end the terminal session, aconfirmation screen is transmitted for display (block 1027), the filesmaintained in mass storage device 84 are updated by the central computer52 (block 1029) and the communications link via PDN network 56 andasynchronous communications interface 60 is terminated (block 1031). If,on the other hand, the user decides to move to another account (astested for by decision block 1033), central computer 52 transmits alisting of other accounts maintained by the user (block 1035) andpermits the user to scroll through this listing to select another bankaccount (blocks 1037,1039,1041). If the user selectsman account (testedfor by decision block 1037), the steps describe previously in connectionwith FIG. 9 blocks 358,388 are performed again (blocks 1043,1045). If,on the other hand, the end of the user account list has been reached,control returns to the main menu routine shown in FIG. 9 (block 1047).

While the invention has been described in connection with what ispresently considered to be the most practical and preferred embodiment,it is to be understood that the invention is not to be limited to thedisclosed embodiment, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims.

What is claimed is:
 1. A method of distributing advertising informationremotely to users comprising the following steps:providing anarrangement to said users that enables the users to access home bankingservices from user terminals; communicating with said user terminals ondemand using a central computer; receiving requests with said centralcomputer from said user terminals; processing said received requestswith said central computer; storing indicia of said processed requestsin a database; obtaining, with said central computer, informationadvertising a product or service from an advertiser; processing saiddatabase to target specific users who may be interested in saidadvertising information; transmitting said advertising information fromsaid central computer to the user terminals operated by said targetedspecific users; prompting said targeted specific users to select whetherthey want further information with respect to said product or service;receiving and testing user responses to said prompting step; andselecting users for delivery of further information relating to theproduct or service based at least in part on whether said users provideat least one predetermined response to said prompting step.
 2. A methodas in claim 1 wherein there is user identifying data corresponding to atleast one of said users, the user identifying data representing theidentity of said at least one user, and said selecting stepcomprises:providing the user identifying data representing the identityof said at least one user to said advertiser in real-time response toreceipt of a response from said at least one user; and contacting saidat least one user in real time response to receipt of said provided useridentifying data.
 3. A method as in claim 1 wherein said selecting stepcomprises:initiating voice communications with at least one of saidusers in real-time response to receipt of a response from said at leastone user.
 4. A method as in claim 1 wherein the user selecting stepincludes the step, conditioned on the user responses to the promptingsteps, of contacting said advertiser and providing said advertiser withthe identity of at least some of said users providing responses.
 5. Amethod as in claim 1 wherein the user selecting step includes the step,conditioned on the user responses to the prompting step, of contactingthe users providing certain responses to provide additional advertisinginformation.
 6. A method of targeting information deliverycomprising:establishing connections with terminals associated withusers; conducting home banking transactions with said users via saidconnections; generating a database at least in part in response to saidhome banking transactions; and targeting information for delivery tosaid terminals via said connections based on the contents of saiddatabase, wherein said method further includes:prompting one of saidusers to provide an input; transmitting a user response to saidprompting step interactively in real time over at least one of saidconnections; and conditionally releasing the identity of said user to aprovider associated with said targeted information based on saidtransmitted response.
 7. A method as in claim 6 further includinginteractively displaying, on displays of said terminals associated withsaid users, data transmitted to said terminals via said connections. 8.A method as in claim 6 wherein the conducting step comprisestransmitting bill paying options to a user terminal and permitting theuser to select between the bill paying options by actuating optionselectors.
 9. A method as in claim 6 wherein the conducting stepcomprises transmitting bill paying options to a user terminal fordisplay on a display, and permitting the user to select between the billpaying options by actuating different option selectors disposed inproximity to the display, and wherein the generating step comprisesrecording the user's bill paying option selections in a confidentialdatabase.
 10. A method of targeting users based at least in part on theusers' remote access to financial services over a network via userterminals, the method comprising the following steps:obtaining, with aremotely located computer, advertising information relating to at leastone product or service; communicating digital information between userterminals and the remotely located computer over a network that enablesthe users to remotely access financial services from their userterminals; storing and processing user requests with said remotelylocated computer and targeting users who may be interested in saidadvertising information; transmitting said advertising information fromsaid remotely located computer to the user terminals operated by saidtargeted users; prompting said targeted users to select whether theywant further information with respect to said product or service;receiving and testing user responses to said prompting step; andselecting users based at least in part on the results of said testingstep.
 11. A method as in claim 10 wherein the selecting step includesselecting users for delivery of further information relating to theproduct or service if said users provide at least one predeterminedresponse to said prompting step.
 12. A method as in claim 10 furtherincluding the step of delivering, to the selected users, furtherinformation relating to the product or service.
 13. A method as in claim10 wherein the communicating step comprises facilitating the users toconduct bill paying transactions on the user terminals.
 14. A method asin claim 10 wherein the communicating step comprises facilitating theusers to conduct home banking transactions on the user terminals.
 15. Amethod as in claim 10 wherein the prompting step includes the step ofdisplaying a prompt message on a miniature multi-line liquid crystaldisplay device included within at least one user terminal, and themethod further includes the step of sensing user depression of at leastone soft key disposed on the user terminal adjacent the liquid crystaldisplay device.
 16. A method as in claim 10 further including the stepof providing a provider of said product or service with the identitiesof at least some users who respond to the prompt.
 17. A method as inclaim 10 wherein the storing and processing step includes the step ofgenerating a database containing user financial transactions, andanalyzing the database to determine user demographic information.
 18. Amethod as in claim 10 wherein the processing step includes the step ofstoring user financial transaction data in at least one database.